@@ -653,7 +653,7 @@ contain the following information about its OCM API:
653653 to the more secure (and possibly required) invite flow.
654654 _ `"receive-code"` - to indicate that this OCM Server can receive a
655655 ` code` as part of a Share Creation Notification, and exchange it
656- for a bearer token at the Sending Server's `/token` API endpoint .
656+ for a bearer token at the Sending Server's tokenEndPoint .
657657 _ `"invite-wayf"` - to indicate that this OCM Server exposes a WAYF
658658 Page to facilitate the Invite flow.
659659* OPTIONAL: criteria (array of string) - The criteria for accepting a
@@ -695,6 +695,11 @@ contain the following information about its OCM API:
695695 ` "/index.php/apps/sciencemesh/accept"` is specified here then a WAYF
696696 Page SHOULD redirect the end-user to
697697` /index.php/apps/sciencemesh/accept?token=zi5kooKu3ivohr9a&providerDomain=example.com` .
698+ * OPTIONAL: tokenEndPoint (string) - URL of the token endpoint where
699+ the Sending Server can exchange a `code` for a bearer token.
700+ Implementations that offer the `"receive-code"` capability MUST
701+ provide this URL as well.
702+ Example : ` "https://my-cloud-storage.org/ocm/token"` .
698703
699704# Share Creation Notification
700705
@@ -767,7 +772,7 @@ To create a Share, the Sending Server SHOULD make a HTTP POST request
767772 that the share does not expire.
768773* OPTIONAL code (string)
769774 A nonce to be exchanged for a (potentially short-lived)
770- bearer token at the Sending Server's /token endpoint.
775+ bearer token at the Sending Server's tokenEndPoint [RFC6749]
771776* REQUIRED protocol (object)
772777 JSON object with specific options for each protocol.
773778 The supported protocols are : - `webdav`, to access the data -
@@ -969,9 +974,10 @@ is as follows:
969974 ` resourceTypes[0].protocols.webdav` value is the
970975 ` <sender-ocm-path>` to be used in step 3.
9719762. If `code` is not empty, the receiver SHOULD make a signed POST
972- request to the `/token` path inside the Sending Server's OCM API , to
977+ request to the path in the Sending Server’s tokenEndPoint , to
973978 exchange the code for a short-lived bearer token, and then use that
974- bearer token to access the Resource.
979+ bearer token to access the Resource (See the [Code Flow](
980+ # code-flow) section).
9759813. If `protocol.name` = `webdav`, the receiver SHOULD inspect the
976982 ` protocol.options` property. If it contains a `sharedSecret`, as in
977983 the [legacy example](
@@ -1002,6 +1008,83 @@ Additionally, if `protocol.<protocolname>.requirements` includes
10021008Party has been authenticated with MFA, or prompt the consumer in order
10031009to elevate their session, if applicable.
10041010
1011+
1012+ # Code Flow
1013+
1014+ This section defines the procedure for issuing short-lived bearer access
1015+ tokens for use by the Receiving Server when accessing a resource shared
1016+ through OCM. The mechanism is aligned with the OAuth 2.0
1017+ *authorization_code* grant type but is performed entirely as a
1018+ server to server interaction between the Sending and Receiving Servers.
1019+ No user interaction or redirect is involved. [RFC6749]
1020+
1021+ # # Token Request
1022+
1023+ To obtain an access token, the Receiving Server MUST send an HTTP POST
1024+ request to the Sending Server’s tokenEndPoint as discovered in the
1025+ OCM provider metadata.
1026+
1027+ ` ` `
1028+ POST {tokenEndPoint} HTTP/1.1
1029+ Host: my-cloud-storage.org
1030+ Date: Wed, 05 Nov 2025 14:00:00 GMT
1031+ Content-Type: application/x-www-form-urlencoded
1032+ Digest: SHA-256=ok6mQ3WZzKc8nb7s/Jt2yY1uK7d2n8Zq7dhl3Q0s1xk=
1033+ Content-Length: 101
1034+ Signature-Input:
1035+ sig1=("@method" "@target-uri" "content-digest" "date"); \
1036+ created=1730815200; keyid="receiver.example.org#2025"; \
1037+ alg="rsa-sha256"
1038+ Signature: sig1=:
1039+ bM2sV2a4oM8pWc4Q8r9Zb8bQ7a2vH1kR9xT0yJ3uE4wO5lV6bZ1cP2rN3qD4tR5hC=:
1040+
1041+ grant_type=authorization_code&
1042+ client_id=receiver.example.org&
1043+ code=ABCD1234
1044+ ` ` `
1045+
1046+ The request MUST be signed using an HTTP Message Signature
1047+ [RFC9421]. The `client_id` identifies the Receiving Server and MUST be
1048+ set to it’s fully qualified domain name. The `code` parameter carries
1049+ the authorization code that was issued by the Sending Server in the
1050+ Share Creation Notification. It is allowed to send the additional
1051+ parameters defined in [RFC6749] for the authorization_code grant type,
1052+ but they MUST be ignored.
1053+
1054+ # # Token Response
1055+
1056+ If the request is valid and the code is accepted, the Sending Server
1057+ MUST respond with HTTP 200 OK and a JSON object containing the issued
1058+ token :
1059+
1060+ ` ` `
1061+ {
1062+ "access_token": "8f3d3f26-f1e6-4b47-9e3e-9af6c0d4ad8b",
1063+ "token_type": "Bearer",
1064+ "expires_in": 300
1065+ }
1066+ ` ` `
1067+ The `access_token` is an opaque bearer credential with no internal
1068+ structure visible to the Receiving Server. The token authorizes the
1069+ Receiving Server to access the shared resource using the appropriate
1070+ transport protocol (e.g., WebDAV). The `expires_in` value indicates
1071+ the token lifetime in seconds. No `refresh_token` is issued, instead
1072+ the same request to the tokenEndPoint MUST be repeated before the
1073+ access_token has expired, to recieve a new `access_token` that can then
1074+ be used in the same manner.
1075+
1076+ # # Error Responses
1077+
1078+ If the request is invalid, the Sending Server MUST return an HTTP 400
1079+ response with a JSON object containing an OAuth 2.0 error code
1080+ [RFC6749] :
1081+ ` ` `
1082+ { "error": "invalid_request" }
1083+ ` ` `
1084+
1085+ Permitted error codes are `invalid_request`, `invalid_client`,
1086+ ` invalid_grant` , `unauthorized_client` and `unsupported_grant_type`.
1087+
10051088# Share Deletion
10061089
10071090A `"SHARE_ACCEPTED"` notification followed by a `"SHARE_UNSHARED"`
@@ -1075,6 +1158,15 @@ The legacy format of an OCM Share Notification with shared secrets is
10751158only provided for backwards compatibility with existing implementations.
10761159Implementers SHOULD NOT use it and prefer short-lived tokens instead.
10771160
1161+ # # Code Flow
1162+
1163+ All `{tokenEndPoint}` requests MUST be transmitted over HTTPS and
1164+ signed using HTTP Signatures. Bearer tokens MUST be treated as
1165+ confidential and never logged, persisted beyond their lifetime, or
1166+ transmitted over unsecured channels.
1167+
1168+
1169+
10781170# References
10791171
10801172# # Normative References
@@ -1097,15 +1189,13 @@ Signatures](https://tools.ietf.org/html/rfc9421)", February 2024.
10971189" [Uniform Resource Identifier (URI): Generic Syntax
10981190](https://datatracker.ietf.org/doc/html/rfc3986)" , January 2005
10991191
1192+ [RFC6749] Hardt, D. (ed), "[The OAuth 2.0 Authorization Framework](
1193+ https://datatracker.ietf.org/html/rfc6749)", October 2012.
1194+
11001195[RFC8615] Nottingham, M. "[Well-Known Uniform Resource Identifiers
11011196(URIs)](https://datatracker.ietf.org/doc/html/rfc8615)", May 2019
11021197
11031198
1104- # # Informative References
1105-
1106- [RFC6749] Hardt, D. (ed), "[The OAuth 2.0 Authorization Framework](
1107- https://datatracker.ietf.org/html/rfc6749)", October 2012.
1108-
11091199# Appendix A: Multi-factor Authentication
11101200
11111201If a Receiving Server exposes the capability `enforce-mfa`, it
0 commit comments