Use sharedSecret in the Code flow

[glpatcern]

As we are now in the process of implementing for real the Code flow and specifying it more accurately as in #292, I'm thinking that we could slightly change the semantic of a Share payload - at a time where we would not break any implementation.

The point is that code and sharedSecret are mutually exclusive as it stands now. We could instead drop code and signal the fact that we require httpsig and the Code flow by adding the corresponding use-code requirement, which would mean that the code to be exchanged is the sharedSecret and that barely using the sharedSecret as bearer token does not work.

Comments? cc @enriquepablo @mickenordin @KrausMatthias

[KrausMatthias]

As far as I understand it, the properties of NewShare.protocol[""] are protocol specific, including the sharedSecret. So if I implement another protocol besides webdav, it doesn't necessarily include the sharedSecret attribute.

I think having code in NewShare and not within individual protocol properties would allow to have a generic token exchange across multiple different protocols, potentially allowing shares offering multiple protocols using the same token.

For protocol specific token exchanges, protocols could still independently use their specific protocol properties e.g. to specify endpoints to push your public key to for addition to "authorized_keys".

So I would go for keeping the separate code field for the generic OCM token exchange, while still allowing protocols to specify their own (additional) mechanisms in their protocol properties.

I guess this is also closely related to #277 , where I guess the generic code exchange flow would not work?

[glpatcern]

I also had in mind #277, and more generally my thought was to consider the Code flow an optional (but enforceable) flow where the specific secret to be used is the protocol-specified one but the flow is swapped to a token exchange.

IMHO, the argument to have a generic token exchange no matter the protocol seems good on the surface, but it would indeed fall short on a case such as #277, and with possibly more generic protocols and use-cases to be introduced in the future, I'd argue that the best abstraction is to leave any auth-related exchange to the protocol-specific properties.

[mickenordin]

I also had in mind #277, and more generally my thought was to consider the Code flow an optional (but enforceable) flow where the specific secret to be used is the protocol-specified one but the flow is swapped to a token exchange.

IMHO, the argument to have a generic token exchange no matter the protocol seems good on the surface, but it would indeed fall short on a case such as #277, and with possibly more generic protocols and use-cases to be introduced in the future, I'd argue that the best abstraction is to leave any auth-related exchange to the protocol-specific properties.

I agree with this I think.

[glpatcern]

Then I'll give it a try to amend the spec by essentially removing code and rewording the requirement.

In fact, the requirement keyword use-code might be converted to must-exchange-token to have better clarity, and the mfa-enforced would go to must-use-mfa for consistency. What do you think?