httpsig and short-lived bearer tokens as alternative to sharedSecret (#…

…98)

* OAuth code as alternative to sharedSecret

This would allow for some more modern security best practices like pre-registering clients and making the access token short-lived and client-bound

* whitespace

* typo

* GNAP instead of OAuth 2.0 Authorization Code flow

GNAP is more appropriate here because it makes way less assumptions about the interaction (in particular it doesn't assume the use of browser redirects)

* camel case

* simplify from GNAP to httpsig+bearer

* clarify language

* `<OCM endpoint>/token`

README.md

@@ -50,6 +50,9 @@ In response to a share creation, the receiving server MAY send back a [notificat
 To access a share, the receiving server MAY use multiple ways, depending on the received payload and on the `protocol.name` property:
 
 * If `protocol.name` = `multi`, the receiver MUST make a HTTP PROPFIND request to `protocol.webdav.uri` to access the remote share. If `protocol.webdav.sharedSecret` is not empty, the receiver MUST pass it as a `Authorization: bearer` header.
+Otherwise, if `protocol.webdav.code` is not empty, the receiver SHOULD discover the sender's OCM endpoint and make a signed POST request to `<OCM endpoint>/token`, to exchange
+the code for a short-lived bearer token,
+and then use that bearer token to access the remote share.
 
 * If `protocol.name` = `webdav`, the receiver SHOULD inspect the `protocol.options` property. If it contains a `sharedSecret`, as in the [legacy example](https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post), then the receiver SHOULD make a HTTP PROPFIND request to `https://<sharedSecret>:@<host><path>`, where `<host>` is the remote server, and `<path>` is obtained by querying the [Discovery](#discovery) endpoint at the remote server and getting `resourceTypes[0].protocols.webdav`. Note that this access method is _deprecated_ and may be removed in a future release of the Protocol.