It depends on WHO is generating the ACL token. For example, If in Slash ACL token is transparent to the Slash User, i.e., it is Slash who is managing this and any Application Client doesn’t have to send the ACL token, then this information can be put in the token.
But, If Slash is not managing this, and ACL token has to come from an Application Client then the issue is that an Application client can’t be trusted. Because, then they can always generate a token using ACL login which disables the webhook, and that won’t be an expected behavior by the Slash User.
I guess, 2nd approach is what is being used.
It is only the Slash User who should be able to disable the webhooks if needed. So, for that all we need is an HMAC which establishes the authenticity of the Slash User, and so a separate JWT with its security config in the GraphQL schema seems the best approach to me for this.
EDIT: ACL may not be enabled in all cases, so this information can’t be merged with the ACL JWT.