El cliente genera un par de claves (normalmente ES256) y envía un encabezado DPoP con un JWT que lleva typ dpop+jwt, la clave pública en el encabezado jwk y los claims jti, htm (método HTTP), htu (URL sin consulta ni fragmento), iat y, cuando presenta un token de acceso, ath (su hash SHA-256). El servidor de autorización vincula el token emitido a la huella digital de la clave (cnf.jkt), y los servidores de recursos comprueban la prueba en cada llamada; los servidores pueden exigir un nonce proporcionado por ellos para limitar las pruebas precalculadas.
DPoP funciona en la capa de aplicación, así que sobrevive a los proxies que terminan TLS y se adapta a navegadores y aplicaciones móviles, a diferencia de los tokens vinculados a mTLS (RFC 8705). Los servidores de recursos deben comprobar que jti sea único dentro de un intervalo corto, el método y la URL, y que la clave de la prueba corresponda al token. El inspector de DPoP valida una prueba y su vinculación con el token.