[OAUTH-WG] Re: New Draft: draft-ambekar-oauth-epop-00 – Enveloped Proof of Possession

[Ashwin Ambekar <[e-mail]>]

Hi Niel

>While I can see the motivation, IMO the HTTP-specificity of DPoP is an
advantage from a security point of view. Otherwise, like this draft, you
end up with lots of crucial checks being conditional.
Are you suggesting separating drafts by protocols or suggesting that other
protocols should not be supported?

>The problem I think you have is that the EPOP proof is wrapping the token
..
>EPOP seems to have the further issue that the proof itself contains ..

The trust establishment pattern you describe as "suspending disbelief" is
the same two-phase model used in certificate-based authentication and
codified in RFC 9883: a self-asserted public key is presented, the relying
party verifies the signature with it (establishing key possession), and
authorization of that key is then confirmed via a separate chain check.
Nobody considers TLS client certificate authentication problematic on these
grounds. EPOP follows the same principle: steps 1–3 establish that the
sender holds the private key; step 8 (cnf.jkt cross-check) establishes that
the AS authorized that key for the nested credential. These answer
different questions and must run in sequence.

On parsing an "untrusted" token: after steps 1–3 pass, the outer token is
not unexamined — its signature has been verified. This proves key
possession. An attacker who wraps a stolen access token in their own EPOP
envelope will pass steps 1–3 but fail step 8, because the cnf.jkt inside
the AS-issued nested token does not match their self-generated JWK
thumbprint. The AS bound that value at issuance; it is not under attacker
control in the resource access flow.

On the cnf.jkt concern: I think there may be a conflation of two distinct
flows. In authorization code exchange, cnf.jkt is client-declared (same as
client_assertion in RFC 7521), and PKCE provides the complementary binding.
In resource access, cnf.jkt is embedded in the AS-issued access token and
is not under attacker control — this is the primary token substitution
defense. In rotation flow, new cnf.jkt is attested by the previously known
EPOP key, which is attested by the underlying refresh token.

On conditionality: DPoP has the same structural characteristic — nonce is
optional, ath is conditional on token type. EPOP's validation algorithm in
§5 is a strict sequential procedure with explicit normative requirements at
each step. I am open to discussion on whether specific conditions in the
draft need tighter language.

Regards
Ashwin

On Wed, May 20, 2026 at 1:04 PM Neil Madden <[e-mail]> wrote:

>
>
> > On 20 May 2026, at 19:52, Ashwin Ambekar <[e-mail]> wrote:
> >
> > 
> > Hi Gabriel,
> >
> > There is a broader point that I think gets missed in the ~ vs nesting
> discussion: neither SD-JWT nor DPoP address sender-constraining for opaque
> access tokens across non-HTTP transports. SD-JWT requires JWT structure —
> it has nothing to work with for opaque tokens. DPoP handles opaque tokens
> on HTTP via ath, but the htm/htu claims make it HTTP-only. A client holding
> an opaque AT on Kafka, MQTT, or SASL has no sender-constraining path under
> either mechanism.
>
> While I can see the motivation, IMO the HTTP-specificity of DPoP is an
> advantage from a security point of view. Otherwise, like this draft, you
> end up with lots of crucial checks being conditional.
>
> >
> > EPOP's ntk treats JWT and opaque tokens identically: the credential goes
> in ntk, the outer envelope provides the proof, and validation follows the
> same path regardless of token format or transport. This uniform treatment
> of opaque tokens across all transports is a primary design goal, not an
> incidental feature.
> > There is a convergence path where SD tokens can be the ntk claim inside
> the EPOP token, which I'll be willing to explore as a follow-on draft if
> you are interested.
>
> The problem I think you have is that the EPOP proof is wrapping the token,
> but the token needs to be validated in order to establish trust in the
> proof key. Sure, you can do that, but it means you have to suspend
> disbelief for a while - validating the EPOP proof based on a self-asserted
> JWK and only much later do you get around to checking if that key is
> trusted. That seems a problematic design to me. (I had a similar concern
> with DPoP, but this seems a step even further down that road). I shouldn’t
> be having to parse an untrusted token to find another token that’ll
> eventually let me tie off the trust knot. That way lies doom.
>
> EPOP seems to have the further issue that the proof itself contains a
> self-asserting cnf/jkt claim that sometimes seems to have to match the jwk
> header (both under attacker control, so pointless), but at other times
> might be a nested token where it matches the outer proof key.
>
> I think there’s just far too much complexity and conditionality in this as
> specified to make a robust security mechanism.
>
> — Neil





Regards
Ashwin Ambekar