OAuth access tokens can be bearer tokens, or bound to a variety of mechanisms including ... DPoP ... Bearer tokens are simple to implement but also have the significant security downside of allowing anyone who sees the access token to use that token.

[HTTPSIG] defines a generic mechanism that is used to sign HTTP requests and responses.

This specification defines means to bind access tokens to a key held by the client ... using [HTTPSIG].

DPoP is very powerful but seemed to me like a rather questionable way to sign HTTP messages, which probably wouldn't have made sense if RFC9421 had been available when it was originally designed. In addition, the requirement for ephemeral keys is kind of confusing, and the "server nonce" thing tends to add an additional RTT right at the times when you need it the least, such as during user login.

This draft offers a way to use RFC9421 instead of DPoP, and also allows the client to use the key in its client metadata rather than generating new ones all the time - both of which look like improvements to me.

In particular I think RFC9421 might be easier for Fediverse developers to work with; at the very least, they'll have to figure it out anyway, so why force them to grapple with DPoP too?