Framing in terms of GNAP

[michielbdejong]

We could inherit a lot of best practices if we could somehow fit OCM into OAuth.
The flow is entirely different from classic OAuth, but maybe not that different from UMA.
When the resource owner picks a "sharee" (user@host), they are basically picking both a requesting party (user) and a client (host).

[michielbdejong]

The flow that starts at the resource server could be called a "RS-first" flow, as opposed to a "client-first" flow.
In the test suite we have been calling it the "share with" flow, to distinguish it from the public link flow.

[glpatcern]

Let me reference the doc you mentioned when we discussed this:
https://github.com/pondersource/surf-token-based-access/blob/main/phase-2/osw-abstract.md

[michielbdejong]

So we can build on https://github.com/pondersource/surf-token-based-access - in particular I designed the client-facing scope info structure with the protocols field matching ours, so that we can reuse that.

So the reasoning would be as follows, starting from standard OAuth Client Credentials Flow:

1. imagine, like in UMA, the requesting party is different from the resource owner, and the resource owner is only involved in the 'set policy decision' step at the beginning of https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#protocol-flow
2. imagine the client is notified when this happens! This is the POST to /shares that is central to OCM
3. imagine the client can discover scope info like in https://github.com/pondersource/surf-token-based-access?tab=readme-ov-file#3-the-client-facing-scope-info-api
4. imagine this scope info is included into the policy-setting notification from step 2.
5. now imagine that instead of using client secret like in the Client Credentials flow, there is a shared secret also included in the access policy notification from step 2.

[michielbdejong]

I think that basically completes the framing! Will try to discuss it with the OAuth experts at OSW this week.

[michielbdejong]

I think a small step to make would be to remove sharedSecret from the payload and instead put in a nonce, which could be equivalent to the code in the authorization code flow. The receiving server would then exchange this code for a short-lived token to access the webdav API.

The simple scenario is where the receiving server is already an API client of the sending server.
A group of servers could share a client registry in the form of something like the ScienceMesh central directory.
Or dynamic client registration could be used in the fully open case.

[michielbdejong]

The main change to our protocol would be #98
The framing of the spec text would help OCM be less exotic and get more potential adoption.
I think the thing to do would be to formulate it as a GNAP extension and then merge all text from the readme and from the OpenAPI spec into an RFC format. So this then becomes part of #99.

[michielbdejong]

I'll re-read https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ and see what OCM would add to GNAP.

[michielbdejong]

I think there are three sides to OCM that we could develop as separate GNAP extensions:

• client instance discovery (the AS initiates the registration of a new client instance, including public key, starting from its .well-known info, possibly doing an additional SRV record first)
• end user discovery (OCM invites and per-user public keys)
• ping to end user [group] (OCM /share POST)

[michielbdejong]

The first two would also be quite valuable on their own for Fediverse and Solid probably.

The third one would also be quite valuable on its own in classic OAuth situations, for instance, GitHub could ping an ecosystem app like a CI or deployment system to notify of the existence of a newly created repo to which the app already has access with its existing API token, or for which it is invited to request access.

[michielbdejong]

Maybe we can adopt server-to-server signatures like https://www.w3.org/wiki/ActivityPub/Primer/Authentication_Authorization and #92
and then use that instead of pure GNAP. Or maybe GNAP allows it?

[michielbdejong]

Done, see #98 (comment)