It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client t

It is viable. Think of workload identity federation as the mechanism for the client to get an bearer token initially, and DPoP as the mechanism for the client to present the access token to a resource server. Each DPoP proof is entirely self-contained, so resource servers don't need to manage any additional state. The only new state is the (usually ephemeral) private key held by the client: 1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within 2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof 3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK. 4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof. 5. Clients generate fresh DPoP proofs and send them along with the access token There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.