Right. The idea is that the short lived cookies would have a very short lived expiration, so even if you get access to it, it isn't very useful.
> The proof of possession should happen at the start of each connection. With HTTP3 you shouldn't need a lot of connections.
That could possibly be workable in some situations, but it would add a lot of complexity to application layer load balancers, or reverse proxies, since they would somehow need to communicate that proof of possession to the backend for every request. And it makes http/3 or http/2 a requirement.
I think imitating TLS (and who knows how many other protocols) by coupling the asymmetric key with a symmetric one instead of a bearer token is the obvious upgrade security wise. That way you could prove possession of the PSK with every request, keep it short lived, and (unlike bearer tokens) keep it hidden from callers of the API.
That said, the DBSC scheme has the rather large advantage that it can be bolted on to the current bearer token scheme with minimal changes and should largely mitigate the current issues.
> The proof of possession should happen at the start of each connection. With HTTP3 you shouldn't need a lot of connections.
That could possibly be workable in some situations, but it would add a lot of complexity to application layer load balancers, or reverse proxies, since they would somehow need to communicate that proof of possession to the backend for every request. And it makes http/3 or http/2 a requirement.