@@ -645,7 +645,7 @@ contain the following information about its OCM API:
645645 to the more secure (and possibly required) invite flow.
646646 _ `"receive-code"` - to indicate that this OCM Server can receive a
647647 ` code` as part of a Share Creation Notification, and exchange it
648- for a bearer token at the Sending Server's `/token` API endpoint .
648+ for a bearer token at the Sending Server's tokenEndPoint .
649649 _ `"invite-wayf"` - to indicate that this OCM Server exposes a WAYF
650650 Page to facilitate the Invite flow.
651651* OPTIONAL: criteria (array of string) - The criteria for accepting a
@@ -687,6 +687,11 @@ contain the following information about its OCM API:
687687 ` "/index.php/apps/sciencemesh/accept"` is specified here then a WAYF
688688 Page SHOULD redirect the end-user to
689689` /index.php/apps/sciencemesh/accept?token=zi5kooKu3ivohr9a&providerDomain=example.com` .
690+ * OPTIONAL: tokenEndPoint (string) - URL of the token endpoint where
691+ the Sending Server can exchange a `code` for a bearer token.
692+ Implementations that offer the `"receive-code"` capability MUST
693+ provide this URL as well.
694+ Example : ` "https://my-cloud-storage.org/ocm/token"` .
690695
691696# Share Creation Notification
692697
@@ -759,7 +764,7 @@ To create a Share, the Sending Server SHOULD make a HTTP POST request
759764 that the share does not expire.
760765* OPTIONAL code (string)
761766 A nonce to be exchanged for a (potentially short-lived)
762- bearer token at the Sending Server's /token endpoint.
767+ bearer token at the Sending Server's tokenEndPoint [RFC6749]
763768* REQUIRED protocol (object)
764769 JSON object with specific options for each protocol.
765770 The supported protocols are : - `webdav`, to access the data -
@@ -961,9 +966,10 @@ is as follows:
961966 ` resourceTypes[0].protocols.webdav` value is the
962967 ` <sender-ocm-path>` to be used in step 3.
9639682. If `code` is not empty, the receiver SHOULD make a signed POST
964- request to the `/token` path inside the Sending Server's OCM API , to
969+ request to the path in the Sending Server’s tokenEndPoint , to
965970 exchange the code for a short-lived bearer token, and then use that
966- bearer token to access the Resource.
971+ bearer token to access the Resource (See the [Code Flow](
972+ # code-flow) section).
9679733. If `protocol.name` = `webdav`, the receiver SHOULD inspect the
968974 ` protocol.options` property. If it contains a `sharedSecret`, as in
969975 the [legacy example](
@@ -994,6 +1000,83 @@ Additionally, if `protocol.<protocolname>.requirements` includes
9941000Party has been authenticated with MFA, or prompt the consumer in order
9951001to elevate their session, if applicable.
9961002
1003+
1004+ # Code Flow
1005+
1006+ This section defines the procedure for issuing short-lived bearer access
1007+ tokens for use by the Receiving Server when accessing a resource shared
1008+ through OCM. The mechanism is aligned with the OAuth 2.0
1009+ *authorization_code* grant type but is performed entirely as a
1010+ server to server interaction between the Sending and Receiving Servers.
1011+ No user interaction or redirect is involved. [RFC6749]
1012+
1013+ # # Token Request
1014+
1015+ To obtain an access token, the Receiving Server MUST send an HTTP POST
1016+ request to the Sending Server’s tokenEndPoint as discovered in the
1017+ OCM provider metadata.
1018+
1019+ ` ` `
1020+ POST {tokenEndPoint} HTTP/1.1
1021+ Host: my-cloud-storage.org
1022+ Date: Wed, 05 Nov 2025 14:00:00 GMT
1023+ Content-Type: application/x-www-form-urlencoded
1024+ Digest: SHA-256=ok6mQ3WZzKc8nb7s/Jt2yY1uK7d2n8Zq7dhl3Q0s1xk=
1025+ Content-Length: 101
1026+ Signature-Input:
1027+ sig1=("@method" "@target-uri" "content-digest" "date"); \
1028+ created=1730815200; keyid="receiver.example.org#2025"; \
1029+ alg="rsa-sha256"
1030+ Signature: sig1=:
1031+ bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ1cP2rN3qD4tR5hC=:
1032+
1033+ grant_type=authorization_code&
1034+ client_id=receiver.example.org&
1035+ code=ABCD1234
1036+ ` ` `
1037+
1038+ The request MUST be signed using an HTTP Message Signature
1039+ [RFC9421]. The `client_id` identifies the Receiving Server and MUST be
1040+ set to it’s fully qualified domain name. The `code` parameter carries
1041+ the authorization code that was issued by the Sending Server in the
1042+ Share Creation Notification. It is allowed to send the additional
1043+ parameters defined in [RFC6749] for the authorization_code grant type,
1044+ but they MUST be ignored.
1045+
1046+ # # Token Response
1047+
1048+ If the request is valid and the code is accepted, the Sending Server
1049+ MUST respond with HTTP 200 OK and a JSON object containing the issued
1050+ token :
1051+
1052+ ` ` `
1053+ {
1054+ "access_token": "8f3d3f26-f1e6-4b47-9e3e-9af6c0d4ad8b",
1055+ "token_type": "Bearer",
1056+ "expires_in": 300
1057+ }
1058+ ` ` `
1059+ The `access_token` is an opaque bearer credential with no internal
1060+ structure visible to the Receiving Server. The token authorizes the
1061+ Receiving Server to access the shared resource using the appropriate
1062+ transport protocol (e.g., WebDAV). The `expires_in` value indicates
1063+ the token lifetime in seconds. No `refresh_token` is issued, instead
1064+ the same request to the tokenEndPoint MUST be repeated before the
1065+ access_token has expired, to recieve a new `access_token` that can then
1066+ be used in the same manner.
1067+
1068+ # # Error Responses
1069+
1070+ If the request is invalid, the Sending Server MUST return an HTTP 400
1071+ response with a JSON object containing an OAuth 2.0 error code
1072+ [RFC6749] :
1073+ ` ` `
1074+ { "error": "invalid_request" }
1075+ ` ` `
1076+
1077+ Permitted error codes are `invalid_request`, `invalid_client`,
1078+ ` invalid_grant` , `unauthorized_client` and `unsupported_grant_type`.
1079+
9971080# Share Deletion
9981081
9991082A `"SHARE_ACCEPTED"` notification followed by a `"SHARE_UNSHARED"`
@@ -1067,6 +1150,15 @@ The legacy format of an OCM Share Notification with shared secrets is
10671150only provided for backwards compatibility with existing implementations.
10681151Implementers SHOULD NOT use it and prefer short-lived tokens instead.
10691152
1153+ # # Code Flow
1154+
1155+ All `{tokenEndPoint}` requests MUST be transmitted over HTTPS and
1156+ signed using HTTP Signatures. Bearer tokens MUST be treated as
1157+ confidential and never logged, persisted beyond their lifetime, or
1158+ transmitted over unsecured channels.
1159+
1160+
1161+
10701162# References
10711163
10721164# # Normative References
@@ -1089,15 +1181,13 @@ Signatures](https://tools.ietf.org/html/rfc9421)", February 2024.
10891181" [Uniform Resource Identifier (URI): Generic Syntax
10901182](https://datatracker.ietf.org/doc/html/rfc3986)" , January 2005
10911183
1184+ [RFC6749] Hardt, D. (ed), "[The OAuth 2.0 Authorization Framework](
1185+ https://datatracker.ietf.org/html/rfc6749)", October 2012.
1186+
10921187[RFC8615] Nottingham, M. "[Well-Known Uniform Resource Identifiers
10931188(URIs)](https://datatracker.ietf.org/doc/html/rfc8615)", May 2019
10941189
10951190
1096- # # Informative References
1097-
1098- [RFC6749] Hardt, D. (ed), "[The OAuth 2.0 Authorization Framework](
1099- https://datatracker.ietf.org/html/rfc6749)", October 2012.
1100-
11011191# Appendix A: Multi-factor Authentication
11021192
11031193If a Receiving Server exposes the capability `enforce-mfa`, it
0 commit comments