Discovery caps - Aka is the /mfa-capable endpoint really necessary?

[michielbdejong]

If '/mfa-capable' is listed as a capability in the Discovery Document, then that already states that MFA requirements are supported, right? So then why would a separate boolean endpoint at /mfa-capable be necessary?

[michielbdejong]

I'm thinking maybe the capabilities should be more like

• send/receive Share Creation Notification already implied by 'enabled'
• the various protocols per resource type already implied by 'resourceTypes'
• the ability to act as a WebDAV client using the old HTTP Basic auth header format -> implied
• the ability to act as an API server using the old HTTP Basic auth header format -> implied
• the ability to act as a WebDAV client hitting the WebDAV base URL -> implied
• the ability to act as a WebDAV server serving the WebDAV base URL -> implied
• the ability to act as a WebDAV client using the intermediate sharedSecret Bearer auth -> implied by API version
• the ability to act as a WebDAV server using the intermediate sharedSecret Bearer auth -> implied by API version
• the ability to act as a WebDAV client to the URI from the Share -> implied by API version
• the ability to act as a WebDAV server for the URI from the Share -> implied by including it in a Share Creation Notification
• the ability to act as a WebDAV client using the new code Bearer to the WebDAV base URL -> announce the 'code-client' cap
• the ability to act as a WebDAV server using the new code Bearer to the WebDAV base URL -> announce the 'code-server' cap
• the ability to sign its own http requests -> announce the 'http-request-signer' cap
• the ability to verify incoming http request signatures -> announce the 'http-request-signature-verifier' cap
• the ability to send an MFA requirement -> announce the 'mfa-requirement-sender' cap
• the ability to receive and honour an MFA requirement -> announce the 'mfa-requirement-enforcer' cap

[glpatcern]

The original idea was that the capabilities were endpoints, and the mfa-capable cap got a "trivial" endpoint. I agree though that caps do not necessarily match endpoints, and now with the recent addition of many more optional caps, it makes sense to expose a list of caps as above, with the endpoints implicitly defined by the specs.

I would support switching to a list of "abstract" caps, where we have to add:

• the ability to receive invitations -> announce the 'invite-acceptor' cap
• the ability to send invitations -> announce the 'invite-sender' cap

This would be a breaking change but limited to OCM 1.1 implementations - essentially only Reva and the ScienceMesh app - so relatively easy to port.

[mickenordin]

I like this!