On the /ocm/token endpoint and its similarity with OIDC

[glpatcern]

Reporting here a discussion happened at our meetings and on the chat.

The idea is to make the /token endpoint "dynamic" and advertised in the Discovery payload, as opposed to hardwire it to /ocm/token. The advantage in doing this breaking change is that at the moment no known EFSS implements the Code flow, which has only been demonstrated by the OCM Stub.

@KrausMatthias: an alternative could be the "token_endpoint" property as it's defined in https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata I don't know how how close we want to align to openid there (that might be misleading as a OCM Token Request is not the same as a OIDC Token Request https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest)

@mickenordin: I think it is a downside that a ocm token request is not the same as an oidc token request. You might want to offload your token handling to a pre existing oidc provider, so the fact that they are almost the same, but not completly is a downside imho.

@glpatcern: I concur that the main driver for that proposal was to reuse a pre-existing OIDC provider. This of course would mean that the downstream logic aligns, which would require the OIDC provider to issue a short-lived token that subsequent WebDAV (or whatever other protocol) exchanges are able to understand. As a matter of fact, we'd reinforce the concept that we build upon existing standards (OIDC and WebDAV).

[KrausMatthias]

I guess one could then use the invite flow to register the Receiving Server as OIDC client, with the Sending Server (or WebDAV server) as OIDC Resource Server, e.g. via a Registration Access Token in the Invite (I think the Registration Access Token is Keycloak specific and not part of OIDC)

I don't know if this should be part of OCM or left to implementations

[glpatcern]

I'm not too familiar with all OIDC flows, but a core "value" of OCM is not to impose any authN/authZ relationship between the Sending and the Receiving Server. At least for us at CERN, registering an OIDC client is an admin-only operation.

Instead, we should see which OIDC flow would allow for a totally anonymous remote party (the Receiving Server) to present a nonce to the Sending Server and receive in exchange a short-lived token, with the only credentials being the fact that it made a Signed HTTP request, and that it is a known OCM Server - yes, the last part is what makes it OCM-specific.