Rationalize criteria and requirements

[glpatcern]

Following recent work on the Code flow (#354) and the discussion at the last OCM meeting, this is a proposal to reword some criteria and requirements, aiming at a more rationalized terminology and reinforcing the fact that criteria are a "must" and act as global requirements.

The currently defined criteria are:

- http-request-signatures
- token-exchange
- denylist
- allowlist
- invite

Where the requirements are:

- must-use-mfa
- must-exchange-token

--

I propose to name the criteria as:

- allowlist
- denylist
- must-exchange-token
- must-invite
- must-use-http-sig
- must-use-mfa

And the requirements as:

- must-exchange-token
- must-use-http-sig
- must-use-mfa

If the proposal is accepted, I can create a PR to adapt the OpenAPI and the I-D.

cc @MahdiBaghbani @mickenordin

[MahdiBaghbani]

Thanks for opening this. I agree the naming around code flow has been confusing for a long time, and cleaner labels help

I wanted to add one constraint from implementation work, because renaming alone does not fully remove the ambiguity that showed up while wiring code flow across Reva and Nextcloud

After OCM-API #354 merged, the distinction that mattered in practice was not only "must" wording, but which artifact carries the rule:

1. discovery versus the Share Creation Notification body

and which server role the text is about

2. Receiving Server inbound admission versus Sending Server outbound share payload

[MahdiBaghbani]

Discovery criteria

today token-exchange, inbound policy

Take provider B. When B publishes token-exchange in discovery criteria, B is describing how B behaves as Receiving Server: B will not accept Share Creation Notifications unless the WebDAV protocol on that notification includes must-exchange-token in protocol.webdav.requirements. In other words, it is an admission rule for incoming shares from remote senders

Share protocol.webdav.requirements

must-exchange-token, per-share contract

When provider A sends a share, A may place must-exchange-token on that share. That is A speaking as Sending Server: whoever consumes the resource as sharee must complete token exchange against A's tokenEndPoint. Legacy direct use of the long-lived sharedSecret for WebDAV access is not enough for that share. The sender is imposing the strict contract on recipients, not describing B's inbound policy

Those two planes are related (the preflight paragraph in #354 ties them together), but they are not the same object. One lives in discovery and gates acceptance of notifications. The other lives on the share payload and gates how access must work for that specific resource

So, discovery criteria is not a global default that fills in protocol.webdav.requirements for shares

Those requirements stay per share on the notification; criteria only states what a receiver will accept inbound and the preflight rules connect the two when both providers can do code flow

[MahdiBaghbani]

I am in favor of the rename direction, sharper must-* labels in discovery will help, my preference would be something different than must-* to distinguish them better both as reader or implementor
The one place I would disagree with the issue text is the idea that criteria "act as global requirements"