From 0e26bc212f17c492b9ac205b0ed16bc2fdeb70ce Mon Sep 17 00:00:00 2001 From: glpatcern <6871173+glpatcern@users.noreply.github.com> Date: Mon, 2 Feb 2026 13:50:51 +0000 Subject: [PATCH] CI: regenerate IETF-RFC.xml for Datatracker Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- IETF-RFC.md | 2 +- IETF-RFC.xml | 1340 +++++++++++++++++++++++++------------------------- 2 files changed, 679 insertions(+), 663 deletions(-) diff --git a/IETF-RFC.md b/IETF-RFC.md index 14f2dde..0138505 100644 --- a/IETF-RFC.md +++ b/IETF-RFC.md @@ -1,6 +1,6 @@ --- title: 'Open Cloud Mesh' -docname: draft-ietf-ocm-open-cloud-mesh-02 +docname: draft-ietf-ocm-open-cloud-mesh-03 category: std ipr: trust200902 diff --git a/IETF-RFC.xml b/IETF-RFC.xml index 4c8f238..c30d758 100644 --- a/IETF-RFC.xml +++ b/IETF-RFC.xml @@ -12,7 +12,7 @@ ]> - + Open Cloud Mesh @@ -45,7 +45,7 @@ - + Applications and Real-Time @@ -763,33 +763,30 @@ The supported recipient share types. MUST contain "federation". Example: ["user"] protocols (object) - The supported protocols for accessing Shared -Resources of this type. -Implementations that offer file Resources MUST -support at least webdav, -any other combination of Resources and protocols is -optional. Example: -json +Resources of this type. Implementations that offer file +Resources MUST support at least webdav, any other combination +of Resources and protocols is optional. Example: + { "webdav": "/remote/dav/ocm/", "webapp": "/app/ocm/", "talk": "/apps/spreed/api/" } - + + Fields: - - webdav (string) - The top-level WebDAV [RFC4918] path at this -endpoint. In order to access a Remote Resource, implementations -SHOULD use this path as a prefix (see sharing examples). - webapp (string) - The top-level path for web apps at this -endpoint. In order to access a remote web app, implementations -SHOULD use this path as a prefix (see sharing examples). - ssh (string) - The top-level address in the form host:port -of an endpoint that supports ssh and scp with a public/private -key based authentication. - Any additional protocol supported for this Resource type MAY be -advertised here, where the value MAY correspond to -a top-level URI to be used for that protocol. - +- webdav (string) - The top-level WebDAV [RFC4918] path at this + endpoint. In order to access a Remote Resource, implementations + SHOULD use this path as a prefix (see sharing examples). +- webapp (string) - The top-level path for web apps at this + endpoint. In order to access a remote web app, implementations + SHOULD use this path as a prefix (see sharing examples). +- ssh (string) - The top-level address in the form host:port + of an endpoint that supports ssh and scp with a public/private + key based authentication. +- Any additional protocol supported for this Resource type MAY be + advertised here, where the value MAY correspond to + a top-level URI to be used for that protocol. OPTIONAL: capabilities (array of string) - The optional capabilities supported by this OCM Server. @@ -798,49 +795,53 @@ to be compliant, it is not necessary to expose that as a capability. Example: ["exchange-token", "webdav-uri"]. The array MAY include one or more of the following items: -_ "enforce-mfa" - to indicate that this OCM Server can apply a -Sending Server's MFA requirements for a Share on their behalf. -_ "exchange-token" - to indicate that this OCM Server exposes a + + "enforce-mfa" - to indicate that this OCM Server can apply a +Sending Server's MFA requirements for a Share on their behalf. + "exchange-token" - to indicate that this OCM Server exposes a [RFC6749]-compliant endpoint, which allows to exchange a secret received in the protocol properties of a Share Creation Notification -for a short-lived bearer token. -_ "http-sig" - to indicate that this OCM Server supports +for a short-lived bearer token. + "http-sig" - to indicate that this OCM Server supports [RFC9421] HTTP Message Signatures and advertises public keys in the format specified by [RFC7517] at the /.well-known/jwks.json -endpoint for signature verification. -_ "invites" - to indicate the server would support acting as an +endpoint for signature verification. + "invites" - to indicate the server would support acting as an Invite Sender or Invite Receiver OCM Server. This might be useful for suggesting to a user that existing contacts might be upgraded -to the more secure (and possibly required) invite flow. -_ "notifications" - to indicate that this OCM Server handles -notifications to exchange updates on shares and invites. -_ "invite-wayf" - to indicate that this OCM Server exposes a WAYF -Page to facilitate the Invite flow. -_ "webdav-uri" - to indicate that this OCM Server can append a +to the more secure (and possibly required) invite flow. + "notifications" - to indicate that this OCM Server handles +notifications to exchange updates on shares and invites. + "invite-wayf" - to indicate that this OCM Server exposes a WAYF +Page to facilitate the Invite flow. + "webdav-uri" - to indicate that this OCM Server can append a relative URI to the path listed for WebDAV [RFC4918] in the appropriate resourceTypes entry "protocol-object" - to indicate that this OCM Server can receive a Share Creation Notification whose protocol object contains one property per supported protocol instead of containing the standard name and options properties. + OPTIONAL: criteria (array of string) - The criteria for accepting a Share Creation Notification. As all Receiving Servers SHOULD require the use of TLS in API calls, it is not necessary to expose that as a criterium. Example: ["http-request-signatures"]. The array MAY include for instance: -_ "http-request-signatures" - to indicate that API requests -without http signatures will be rejected. -_ "token-exchange" - to indicate that API requests without + + "http-request-signatures" - to indicate that API requests +without http signatures will be rejected. + "token-exchange" - to indicate that API requests without token exchange will be rejected (see the Code Flow -section). -_ "denylist" - some servers MAY be blocked based on their IP -address -_ "allowlist" - unknown servers MAY be blocked based on their IP -address -_ "invite" - an invite MUST have been exchanged between the +section). + "denylist" - some servers MAY be blocked based on their IP +address + "allowlist" - unknown servers MAY be blocked based on their IP +address + "invite" - an invite MUST have been exchanged between the sender and the receiver before a Share Creation Notification can be sent + DEPRECATED: publicKey (object) - Use public keys at /.well-known/jwks.json instead for RFC 9421 support. OPTIONAL: inviteAcceptDialog (string) - URL path of a web page where @@ -1246,7 +1247,7 @@ request payload MUST be in x-www-form-urlencoded for in the following example (with line breaks in the Signature headers for display purposes only): -``` + POST {tokenEndPoint} HTTP/1.1 Host: cloud.example.org Date: Wed, 05 Nov 2025 14:00:00 GMT @@ -1259,12 +1260,12 @@ Signature-Input: keyid="receiver.example.org#key1"; alg="rsa-sha256" Signature: sig1=:bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ1cP - 2rN3qD4tR5hC=: + 2rN3qD4tR5hC=: -grant_type=authorization_code& +grant_type=authorization_code& client_id=receiver.example.org& code=my_secret_code -``` + The request MUST be signed using an HTTP Message Signature [RFC9421]. The client_id identifies the Receiving Server and MUST be @@ -1281,7 +1282,7 @@ but they MUST be ignored. MUST respond with HTTP 200 OK and a OAuth-compliant JSON object containing the issued token: - + { "access_token": "8f3d3f26-f1e6-4b47-9e3e-9af6c0d4ad8b", "token_type": "Bearer", @@ -1303,8 +1304,9 @@ then be used in the same manner. If the request is invalid, the Sending Server MUST return an HTTP 400 response with a JSON object containing an OAuth 2.0 error code -[RFC6749]: - +[RFC6749]: + + { "error": "invalid_request" } @@ -1545,7 +1547,7 @@ public keys at /.well-known/jwks.json in the format [RFC7517]. Here is an example response from https://sender.example.org/.well-known/jwks.json: -json + { "keys": [ { @@ -1563,14 +1565,14 @@ public keys at /.well-known/jwks.json in the format Given a Share Creation Notification request: -``` + POST /ocm/shares HTTP/1.1 Host: receiver.example.org Date: Fri, 16 Jan 2026 13:37:00 GMT Content-Type: application/json -Content-Digest: sha-256=:LkpHyFOVbBDPxc7YbHDOWNzAv88qWuVfLNf4TUf9Uo8=: +Content-Digest: sha-256=:LkpHyFOVbBDPxc7YbHDOWNzAv88qWuVfLNf4TUf9Uo8=: -{ +{ "shareWith": "marie@receiver.example.org", "name": "spec.yaml", "providerId": "7c084226-d9a1-11e6-bf26-cec0c932ce01", @@ -1589,31 +1591,31 @@ Content-Digest: sha-256=:LkpHyFOVbBDPxc7YbHDOWNzAv88qWuVfLNf4TUf9Uo8=: } } } -``` + The signature base is constructed according to [RFC9421] (with line breaks in @signature-params for display purposes only): - + "@method": POST "@target-uri": https://receiver.example.org/ocm/shares -"content-digest": sha-256=:<digest-value>=: +"content-digest": sha-256=:[digest-value]=: "@signature-params": ("@method" "@target-uri" "content-digest"); - created=<timestamp>; + created=[timestamp]; keyid="sender.example.org#key1"; alg="ed25519" - + Sign this base using for example Ed25519 ([RFC8032]) to produce the signature, then add headers (line breaks for display purposes only): - + Signature-Input: sig1=("@method" "@target-uri" "content-digest"); - created=<timestamp>; + created=[timestamp]; keyid="sender.example.org#key1"; alg="ed25519" -Signature: sig1=:<signature-value>=: - +Signature: sig1=:[signature-value]=: +
Verifying a Signature (Receiver) @@ -1677,7 +1679,7 @@ Example: -json + { "payload": { "federation": "The ScienceMesh Directory", @@ -1725,7 +1727,7 @@ flow or direct entry. It provides a convenient way for users to organize and access their federated contacts, and MAY allow users to generate Invites. - +
Invites. +-----------------+ +----------------+ | Contact | | Invites | +-----------------+ +----------------+ - -### Properties +]]>
+ +
Properties owner: Reference to the User who owns this address book contacts: Array of Contact objects stored in the address book +
Relationships @@ -1764,7 +1768,7 @@ created through the Invite process or via direct entry. A Contact MAY of course contain much more detailed information about the referenced user such as if it was added via Invites or direct entry. - +
Invites or direct entry. +-----------------+ | Address Book | +-----------------+ - -### Properties +]]>
+ +
Properties addedDate: Timestamp of when contact was added @@ -1791,6 +1796,7 @@ user such as if it was added via Invites or direct entry. provider: The FQDN of the contact's OCM Server +
Relationships @@ -1805,7 +1811,7 @@ user such as if it was added via Invites or direct entry. mechanism in OCM. It facilitates secure contact exchange between users on different OCM Servers. -``` +
v +-----------------+ | Address Book | -+-----------------+ ++-----------------+ + +]]>
-``` -### Properties +
Properties acceptedTime: Timestamp of invite acceptance (if accepted) @@ -1832,6 +1839,7 @@ on different OCM Servers. OCM Server +
Relationships @@ -1850,7 +1858,7 @@ implementor might find it useful to have a Provider object model to store the discovered information about federation peers or other remote OCM Providers. - +
| - webdav | | - ... | +------------------+ - +]]>
-
Properties +
Properties apiVersion: Version string of supported OCM API @@ -1910,7 +1918,7 @@ OCM Providers. The Share entity represents a policy granting access to a Resource from a Sending Party to a Receiving Party. - +
| creates | accesses v v +------------------+ notification +------------------+ -| Share |-------------------->| Receiving Server | +| Share |-------------------->| Receiving Server | +------------------+ +------------------+ | - expiration | | | - name | | mediates access to @@ -1938,9 +1946,9 @@ from a Sending Party to a Receiving Party. +-----------------+ | Resource | +-----------------+ - +]]>
-
Properties +
Properties expiration: Optional expiration timestamp @@ -1982,15 +1990,15 @@ from a Sending Party to a Receiving Party. The User entity represents the party in OCM who can send and receive Shares and Invites and manage Contacts, and interact with Resources. - - +-----------------------+ - | User | - +-----------------------+ - | - email | - | - name | - | - ocmAddress | - | - uid | - +-----------------------+ +
+------------------+ | - sent[] | +------------------+ - +]]>
-
Properties +
Properties email: User's email address @@ -2041,7 +2049,7 @@ Receiving Party through the Sending Server's API. In general a Resource is a much more complex entity, but for the purpose of OCM we only need to model a few key properties. - +
+------------------+ | Share | +------------------+ - +]]>
-
Properties +
Properties location: URI or path to access the Resource @@ -2079,9 +2087,15 @@ version in the IETF datatracker. It is meant to ease the review process and it shall be removed when going to RFC last call. The complete changelog is updated in the OCM-API GitHub repository. +
Version 03 + + Fixed formatting of artworks, code blocks and bullet lists. + + +
Version 02 - Added the Changes section + Added the Changes section.
@@ -2157,570 +2171,572 @@ Tilo Steiger, C.D. Tiwari, Alejandro Unger and Tom Wezepoel.