@@ -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,81 @@ 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: sig1=("@method" "@target-uri" "content-digest" "date"); \
1027+ created=1730815200; keyid="receiver.example.org#2025"; \
1028+ alg="rsa-sha256"
1029+ Signature: sig1=:bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ1cP2rN3qD4tR5hC=:
1030+
1031+ grant_type=authorization_code&
1032+ client_id=receiver.example.org&
1033+ code=ABCD1234
1034+ ` ` `
1035+
1036+ The request MUST be signed using an HTTP Message Signature
1037+ [RFC9421]. The `client_id` identifies the Receiving Server and MUST be
1038+ set to its fully qualified domain name. The `code` parameter carries the
1039+ authorization code that was issued by the Sending Server in the Share
1040+ Creation Notification. It is allowed to send the additional parameters
1041+ defined in [RFC6749] for the authorization_code grant type, but they
1042+ MUST be ignored.
1043+
1044+ # # Token Response
1045+
1046+ If the request is valid and the code is accepted, the Sending Server
1047+ MUST respond with HTTP 200 OK and a JSON object containing the issued
1048+ token :
1049+
1050+ ` ` `
1051+ {
1052+ "access_token": "8f3d3f26-f1e6-4b47-9e3e-9af6c0d4ad8b",
1053+ "token_type": "Bearer",
1054+ "expires_in": 300
1055+ }
1056+ ` ` `
1057+ The `access_token` is an opaque bearer credential with no internal
1058+ structure visible to the Receiving Server. The token authorizes the
1059+ Receiving Server to access the shared resource using the appropriate
1060+ transport protocol (e.g., WebDAV). The `expires_in` value indicates
1061+ the token lifetime in seconds. No `refresh_token` is issued, instead
1062+ the same request to the tokenEndPoint MUST be repeated before the
1063+ access_token has expired, to recieve a new `access_token` that can then
1064+ be used in the same manner.
1065+
1066+ # # Error Responses
1067+
1068+ If the request is invalid, the Sending Server MUST return an HTTP 400
1069+ response with a JSON object containing an OAuth 2.0 error code
1070+ [RFC6749] :
1071+ ` ` `
1072+ { "error": "invalid_request" }
1073+ ` ` `
1074+
1075+ Permitted error codes are `invalid_request`, `invalid_client`,
1076+ ` invalid_grant` , `unauthorized_client` and `unsupported_grant_type`.
1077+
9971078# Share Deletion
9981079
9991080A `"SHARE_ACCEPTED"` notification followed by a `"SHARE_UNSHARED"`
@@ -1067,6 +1148,15 @@ The legacy format of an OCM Share Notification with shared secrets is
10671148only provided for backwards compatibility with existing implementations.
10681149Implementers SHOULD NOT use it and prefer short-lived tokens instead.
10691150
1151+ # # Code Flow
1152+
1153+ All `{tokenEndPoint}` requests MUST be transmitted over HTTPS and
1154+ signed using HTTP Signatures. Bearer tokens MUST be treated as
1155+ confidential and never logged, persisted beyond their lifetime, or
1156+ transmitted over unsecured channels.
1157+
1158+
1159+
10701160# References
10711161
10721162# # Normative References
@@ -1089,15 +1179,13 @@ Signatures](https://tools.ietf.org/html/rfc9421)", February 2024.
10891179" [Uniform Resource Identifier (URI): Generic Syntax
10901180](https://datatracker.ietf.org/doc/html/rfc3986)" , January 2005
10911181
1182+ [RFC6749] Hardt, D. (ed), "[The OAuth 2.0 Authorization Framework](
1183+ https://datatracker.ietf.org/html/rfc6749)", October 2012.
1184+
10921185[RFC8615] Nottingham, M. "[Well-Known Uniform Resource Identifiers
10931186(URIs)](https://datatracker.ietf.org/doc/html/rfc8615)", May 2019
10941187
10951188
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-
11011189# Appendix A: Multi-factor Authentication
11021190
11031191If a Receiving Server exposes the capability `enforce-mfa`, it
0 commit comments