This is certainly true for schemes that require trips to a source-of-truth database to authorize a token (c->auth, c->resource, resource->auth). It's also true for schemes where the token is associated with capabilities that are loaded from a database. Using JWT to implement RBAC is flawed.
However, there is a strong use case for the token carrying its own capabilities -- that is, a token that is more than just "20 bytes of urandom".
If a resource service can derive the capabilities associated with a token generated by a trusted authentication service without contacting that service, that has real world implications for lower latency, higher throughput applications that are simpler to compose and operate.
As far the cryptographic credibility, the idea behind capability-based security is an old one, and I'm sure you're aware of the research. This particular spec may be problematic, folks may be misunderstanding and misusing the primitives, but the underlying idea is sound.
Previous HN discussion of CapSec Wikipedia article
The issue isn't with capabilities, or delegated authentication, or public key tokens, or even standardizing any of those things. I think at this point I've been pretty clear about what I believe the issues actually are.
Do you have a standard that you would recommend for any of those things?
- crypto_auth, or HMAC-SHA256 by itself, for authentication
- crypto_secretbox for symmetric encryption
- crypto_box or TLS for public key encryption
Echoing tptacek's comment above: the problems with using those individual pieces is in the joinery - combining them in ways that are broken.