Skip to content

Prepare version 1.4 #378

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
glpatcern merged 2 commits into from
Jun 23, 2026
Merged

Prepare version 1.4 #378

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f4312c2
Added references to the new I-Ds
glpatcern Jun 21, 2026
1de6668
Prepare version 1.4
glpatcern Jun 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,27 @@
# Changelog

## [1.4.0] - 2026-06-23 - Giuseppe Lo Presti <lopresti@cern.ch>

* Introduced a `/request-share` endpoint to request a user of an
OCM server to share a resource.
* Refactored the `webapp` protocol to align it to the new security
standard, by means of POST requests and the Code Flow.
* Introduced new `<protocol>-receive` protocols in the Discovery
endpoint, to signal the ability to receive an OCM share carrying
that protocol.
* Introduced new Internet-Draft specifications to cover optional
parts of the protocol related to webapp integrations and federated
groups.
* Renamed some requirements and criteria to improve consistency.
* On a Share Creation Notification, made the `sharedSecret`
a required parameter for all protocol payloads that specify it.
* Fixed all example URIs to use `example.org` across the spec.
* Improved the JWKS-related text and fixed obsoleted references.
* Removed the already deprecated `/ocm-provider` endpoint and the
draft-cavage public key advertisement in the OCM Discovery endpoint
as all known implementations have migrated to the recommended
alternatives.

## [1.3.0] - 2026-01-20 - Micke Nordin <kano@sunet.se>

* First edition of the draft after IETF Working Group adoption.
Expand Down
54 changes: 46 additions & 8 deletions IETF-OCM.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -663,7 +663,7 @@ 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.3.0"`
supports. Example: `"1.4.0"`
* REQUIRED: endPoint (string) - The URI of the OCM API available at
this endpoint. Example: `"https://cloud.example.org/ocm"`
* OPTIONAL: provider (string) - A friendly branding name of this
Expand Down Expand Up @@ -839,7 +839,11 @@ MUST expose the `exchange-token` capability and a `tokenEndPoint`,
because WebApp access requires the Receiving Server to exchange
`protocol.webapp.sharedSecret` before presenting the WebApp to the
browser. If the Sending Server cannot offer this code flow, it MUST NOT
include `protocol.webapp` in the notification.
include `protocol.webapp` in the notification. A Sending Server MAY
serve Web apps either from the same hosting infrastructure or from
external servers in the same organization: to facilitate the integration
of external servers, the RECOMMENDED reference implementation is
described at [OCM-IP].

## Fields

Expand Down Expand Up @@ -885,8 +889,9 @@ include `protocol.webapp` in the notification.
Server.
In the federation case, OCM Servers MAY resolve the actual
recipients by either querying external AAI systems, or exchanging
the groups' metadata between themselves. Such exchange is out of
scope for this version of the this specification.
the groups' metadata between themselves. For the latter, the
RECOMMENDED implementation is based on the MLS protocol and it is
described in [OCM-MLS].
Alternatively, the Receiving Server MAY hold the federated groups'
metadata and act as an OCM proxy, forwarding the OCM requests to
the actual members of the federation.
Expand All @@ -903,9 +908,10 @@ include `protocol.webapp` in the notification.
available for an efficient data transfer to the destination server.
* REQUIRED protocol (object)
JSON object with specific options for each protocol.
The supported protocols are: - `webdav`, to access the data -
`webapp`, to access remote web applications - `ssh`, to access
the data via a public/private key pair.
The supported protocols are:
- `webdav`, to access the data via HTTP WebDAV.
- `webapp`, to access remote web applications.
- `ssh`, to access the data via a public/private key pair.
Other custom protocols might be added in the future.
In case a single protocol is offered, there are three ways to
specify this object:
Expand Down Expand Up @@ -1624,6 +1630,18 @@ https://datatracker.ietf.org/doc/html/rfc9530)", February 2024.
Representation of Contact Data](
https://datatracker.ietf.org/doc/html/rfc9553), May 2024"

## Informative References

[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open
Cloud Mesh Integration
Protocol](https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/)",
Work in Progress, Internet-Draft.

[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "[Federated
Groups in Open Cloud Mesh using Messaging Layer
Security](https://datatracker.ietf.org/doc/draft-nordin-ocm-mls-federated-groups/)",
Work in Progress, Internet-Draft.


# Appendix A: Multi-factor Authentication

Expand Down Expand Up @@ -2212,6 +2230,27 @@ 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 05
* Introduced a `/request-share` endpoint to request a user of an
OCM server to share a resource.
* Refactored the `webapp` protocol to align it to the new security
standard, by means of POST requests and the Code Flow.
* Introduced new `<protocol>-receive` protocols in the Discovery
endpoint, to signal the ability to receive an OCM share carrying
that protocol.
* Introduced new Internet-Draft specifications to cover optional
parts of the protocol related to webapp integrations and federated
groups.
* Renamed some requirements and criteria to improve consistency.
* On a Share Creation Notification, made the `sharedSecret`
a required parameter for all protocol payloads that specify it.
* Fixed all example URIs to use `example.org` across the spec.
* Improved the JWKS-related text and fixed obsoleted references.
* Removed the already deprecated `/ocm-provider` endpoint and the
draft-cavage public key advertisement in the OCM Discovery endpoint
as all known implementations have migrated to the recommended
alternatives.

## Version 04
* Clarified that the diagrams in Appendix D are illustrative and
not normative.
Expand All @@ -2224,7 +2263,6 @@ The complete changelog is updated in the OCM-API GitHub repository.
* Added the _Changes_ section.

## Version 01

* Introduced functions, roles, and object models to the specification.
* Added support for SSH as a share access method.
* Introduced `accessType` property in shares and removed the datatx
Expand Down
4 changes: 2 additions & 2 deletions spec.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ info:
Open Cloud Mesh OpenAPI Specification.
The semantic of the Protocol Specification is detailed in the OCM Internet-Draft document
published at the [IETF Datatracker](https://datatracker.ietf.org/doc/draft-ietf-ocm-open-cloud-mesh).
version: 1.3.0
version: 1.4.0
x-logo:
url: logo.png
servers:
Expand Down Expand Up @@ -354,7 +354,7 @@ components:
apiVersion:
type: string
description: The OCM API version this endpoint supports
example: 1.3.0
example: 1.4.0
endPoint:
type: string
description: The URI of the OCM API available at this endpoint
Expand Down
Loading