From f104d191ee7936b913f1094946638ad9b1e909cc Mon Sep 17 00:00:00 2001 From: Matthias Kraus Date: Fri, 22 Aug 2025 11:08:48 +0200 Subject: [PATCH 1/6] Specify the OCM Address format Following discussion in #237 and #244 --- IETF-RFC.md | 40 ++++++++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 8 deletions(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index aba1aa32..0525ed2d 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -139,14 +139,31 @@ related concepts from OAuth [RFC6749] and elsewhere: OCM API Discovery. * __Discoverable Server__ - A server that tries to supply information in OCM API Discovery. -* __OCM Address__ - A string of the form - `@` which can be used to uniquely - identify a user or group "at" an OCM Server and MAY be referred to as - Federated Cloud ID. - `` is an opaque string, unique at the - server. `` 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 Address__ - identifies a user or group "at" an OCM Server. +The OCM Address contains a server specific Party identifier, a host +locating the OCM Server and an optional port. The OCM Address is not a +URI as it does not have scheme and the identifier may contain reserved +characters. + + ocm-address = identifier "@" host [ ":" port] + + The identifier is an opaque, case-sensitive utf-8 string. It is + separated from the host by the last "@" in the OCM Address. + host is an IP literal encapsulated within square brackets, an IPv4 + address in dotted decimal form, or a registered name as described in + [RFC3986]. + + host = IP-literal / IPv4address / reg-name + + The optional port subcomponent can be used to specify a port to use + for discovery. Implementers SHOULD omit the port component and its + ":" delimiter if its value would be the same as the default ports + "443" or "80" of HTTPS or HTTP. + + The OCM Server MUST be discoverable at the given host and optional + port via the Well-Known [RFC8615] path `/.well-known/ocm`. The OCM + Address MUST NOT contain a path. + * __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 @@ -1001,6 +1018,13 @@ Key Words](https://datatracker.ietf.org/html/rfc8174)", May 2017. [RFC9421] Backman, A., Richer, J. and Sporny, M. "[HTTP Message Signatures](https://tools.ietf.org/html/rfc9421)", February 2024. +[RFC3986] Berners-Lee, T., Fielding, R. and Masinter, L. +"[Uniform Resource Identifier (URI): Generic Syntax +](https://datatracker.ietf.org/doc/html/rfc3986)", January 2005 + +[RFC8615] Nottingham, M. "[Well-Known Uniform Resource Identifiers +(URIs)](https://datatracker.ietf.org/doc/html/rfc8615)", May 2019 + ## Informative References From 00d807cd549b992d0c0371aab4bc7fccb0560370 Mon Sep 17 00:00:00 2001 From: Matthias Kraus Date: Fri, 22 Aug 2025 13:23:40 +0200 Subject: [PATCH 2/6] Note explicitly there might be multiple @ signs in an OCM Address --- IETF-RFC.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 0525ed2d..0c698d0f 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -148,7 +148,11 @@ characters. ocm-address = identifier "@" host [ ":" port] The identifier is an opaque, case-sensitive utf-8 string. It is - separated from the host by the last "@" in the OCM Address. + separated from the host by the last "@" in the OCM Address. It is + possible to have multiple @-signs in a OCM-address, e.g. when an + email address is the local part of the address like + `nomen.nescio@example.org@ocm.example.org`. + host is an IP literal encapsulated within square brackets, an IPv4 address in dotted decimal form, or a registered name as described in [RFC3986]. From 87ad6c56466d8e16b9f07fd670fdc708ba343175 Mon Sep 17 00:00:00 2001 From: KrausMatthias <40459408+KrausMatthias@users.noreply.github.com> Date: Fri, 22 Aug 2025 17:08:17 +0200 Subject: [PATCH 3/6] Fix to upper case UTF-8 Co-authored-by: Giuseppe Lo Presti --- IETF-RFC.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 0c698d0f..78c3f0ac 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -147,7 +147,7 @@ characters. ocm-address = identifier "@" host [ ":" port] - The identifier is an opaque, case-sensitive utf-8 string. It is + The identifier is an opaque, case-sensitive UTF-8 string. It is separated from the host by the last "@" in the OCM Address. It is possible to have multiple @-signs in a OCM-address, e.g. when an email address is the local part of the address like From f38d6afd48a1245293ca011222bbf6be8603d292 Mon Sep 17 00:00:00 2001 From: Matthias Kraus Date: Mon, 25 Aug 2025 17:25:28 +0200 Subject: [PATCH 4/6] Add Opt-In http discovery as fallback for testing setups --- IETF-RFC.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 78c3f0ac..1325980a 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -516,7 +516,9 @@ Step 4: If not, try a HTTP GET with `https:///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 7. -Step 6: If not, fail. +Step 6: If not, fail. Implementations MAY fallback to `http` instead +`https` in testing setups and retry steps 2-5 using `http`. This SHOULD +only be allowed as Opt-In. Step 7: The JSON response body is the data that was discovered. ## Fields From 2729d73380dc4237a11381cda2e183337bb32ed6 Mon Sep 17 00:00:00 2001 From: KrausMatthias <40459408+KrausMatthias@users.noreply.github.com> Date: Thu, 28 Aug 2025 10:48:39 +0200 Subject: [PATCH 5/6] Drop mention of omitting default ports in favor of mention in Discovery Process Co-authored-by: Giuseppe Lo Presti --- IETF-RFC.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 1325980a..078119c0 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -160,9 +160,7 @@ characters. host = IP-literal / IPv4address / reg-name The optional port subcomponent can be used to specify a port to use - for discovery. Implementers SHOULD omit the port component and its - ":" delimiter if its value would be the same as the default ports - "443" or "80" of HTTPS or HTTP. + for discovery (see Discovery Process). The OCM Server MUST be discoverable at the given host and optional port via the Well-Known [RFC8615] path `/.well-known/ocm`. The OCM From 97e7c4df8e5450532d5ef1c943f2bd0741eca2f6 Mon Sep 17 00:00:00 2001 From: KrausMatthias <40459408+KrausMatthias@users.noreply.github.com> Date: Thu, 28 Aug 2025 10:49:47 +0200 Subject: [PATCH 6/6] Drop suggestion to allow http fallback only as Opt-In Co-authored-by: Giuseppe Lo Presti --- IETF-RFC.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 078119c0..e2c1bb1b 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -514,9 +514,9 @@ Step 4: If not, try a HTTP GET with `https:///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 7. -Step 6: If not, fail. Implementations MAY fallback to `http` instead -`https` in testing setups and retry steps 2-5 using `http`. This SHOULD -only be allowed as Opt-In. +Step 6: If not, fail. Implementations MAY fallback to HTTP instead +of HTTPS in testing setups and retry steps 2-5, in particular when +an optional port is given in the address. Step 7: The JSON response body is the data that was discovered. ## Fields