Клиент генерирует пару ключей (обычно ES256) и отправляет заголовок DPoP с JWT, у которого typ равен dpop+jwt, открытый ключ находится в заголовке jwk, а в утверждениях указаны jti, htm (HTTP-метод), htu (URL без строки запроса и фрагмента), iat и, если предъявляется токен доступа, ath (его хеш SHA-256). Сервер авторизации привязывает выданный токен к отпечатку ключа (cnf.jkt), а серверы ресурсов проверяют доказательство при каждом вызове; серверы могут требовать nonce, выданный самим сервером, чтобы ограничить использование заранее вычисленных доказательств.
DPoP работает на прикладном уровне, поэтому, в отличие от токенов с привязкой через mTLS (RFC 8705), переживает прокси, завершающие TLS, и подходит для браузеров и мобильных приложений. Серверы ресурсов обязаны проверять уникальность jti в пределах короткого окна, метод и URL, а также то, что ключ доказательства соответствует токену. Инспектор DPoP проверяет доказательство и его привязку к токену.