Three security concerns I think we can improve on

[michielbdejong]

I'm trying to look at OCM through GNAP glasses, and notice the following:

short-lived and client-bound access tokens

In the current design, the access token is not short-lived and not client-bound. Apart from that it is pro-actively pushed from the AS (sending server) to the client instance (receiving server); I don't know exactly what the problem with that is, but I do know that for instance FAPI-CIBA prohibits that pattern. To fix this, I think we should include a nonce instead of a sharedSecret in the /shares POST.

unsolicited client instance registration

The proactive notification of a new share feels fine, but we need to remove the sharedSecret from it. Dynamic client instance registration as part of the invite flow is OK I think, but dynamic client instance registration as part of the share-with and public-link flows feels a bit more problematic, since it seems it could more easily be used for spam and phishing

resharing

Resharing feels problematic, especially if it triggers unsolicited dynamic client instance registration (see previous section). Even apart from that, there seems to be no good way for the AS to establish the identity of the end user who requests the reshare. Maybe we can find a way to make it more secure?

[michielbdejong]

OTOH unsolicited client instance registration may make sense for some use cases such as pro-actively sending a document to someone just like you would send it via the fediverse or via email. The AS admin just needs to keep track of which client instance was registered by which RO and for which purpose, and keep audit trails of it.

[michielbdejong]

We should probably layer things a bit in the new spec text, so strict servers will not action reshare requests, but more social ones will. Merging this into #99.