[CAP-89] Host functions for invoker-less authorization

[dmkozh]

This is a discussion thread for CAP-89: Host functions for invoker-less authorization.

The CAP has been motivated by the recent issue in custom account delegation implementation: GHSA-jpg9-m7w4-c7wc

[leighmcculloch]

I'm trying to think of what a set of best practices would be for when to use require_auth vs when to use require_auth_no_invoker. It is not entirely clear to me, which concerns me a little because it may be difficult for developers to know which they should reach for.

Picking either has subtle but material consequences.

For example, picking require_auth when you need require_auth_no_invoker potentially results in issues like the one noted above.

However, picking require_auth_no_invoker when you could safely use require_auth potentially limits the composability of your contract and creates surprising not-obvious auth failures that will be difficult for a caller to understand what they are doing wrong.

When there are two ways to do something, and one way is safer, I think there will be a tendency for that safer way to be the default, which I don't think is what we want to happen with require_auth. Composability is harder to test exhaustively, so picking the wrong one may get missed during general testing, so testing is unlikely to guide a developer towards picking the right one.

Do you have sense of what a decision tree / set of best practices would look like for that?

[leighmcculloch]

disable invoker auth for __check_auth frames entirely

If this approach was taken, and a contract needed to authorise a direct invoke, would they be able to use authorize_as_current_contract?

[dmkozh]

If this approach was taken, and a contract needed to authorise a direct invoke, would they be able to use authorize_as_current_contract?

Not sure who is 'they' in this case, but authorize_as_current_contract authorizes only 'deep' calls, i.e. those that start at depth 2 or greater relative to the authorizer. Moreover, the suggestion there is to disable invoker auth entirely, i.e. no invoker machinery would be involved, neither deep nor shallow. So from both angles the answer is 'no', no matter whether you mean the direct caller, or the callers up the stack.

[leighmcculloch]

disable invoker auth entirely

So CAP-89 will prevent any form of contract authorisation from taking place through the use of both:

• implicit direct invoker auth
• and, explicit invoker auth with a depth greater than 2?

So CAP-89 really isn't just "invoker auth", which I think intuitively sounds like A invokes B and auths automatically, it is a mode where auth from outside of the execution is required?

[leighmcculloch]

Because of the ambiguity about what invoker auth is, naming these fns so they signal that the external requirement for auth would make the use case clearer, the impact/side-effects clearer, and improve the decision tree. e.g. require_external_auth or require_offchain_auth or something to that effect. Neither of those names are great, but maybe there is a better one.

[dmkozh]

So CAP-89 will prevent any form of contract authorisation from taking place through the use of both:

No, CAP-89 introduces host functions that require auth, but don't allow invoker authorization, i.e. they require an explicit signature to be attached to the transaction. So your bullet points would be true only for an address for which require_auth_no_invoker is called, but not for the existing require_auth calls. The quoted fragment is about the alternative approach not taken in the CAP, where we disable invoker auth in __check_auth frames unconditionally (i.e. every require_auth in __check_auth would behave as CAP-89 require_auth_no_invoker).

e.g. require_external_auth or require_offchain_auth or something to that effect

Agree, we could change the 'polarity' of the name. require_external_auth sounds fine to me, but I'll think a bit more for potentially a better name.