> On 25 May 2026, at 17:46, Ashwin Ambekar <[email protected]> wrote:
>
> 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?
I'm suggesting that protocol-specific security mechanisms are much more likely
to be securely implemented than generic ones. As a general principle, all
critical security checks should be either MUST or MUST NOT without conditions.
Otherwise you create cracks at which attackers can apply pressure.
>
> >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.
I'm not sure what you're alluding to here - client certificate authentication
works with a pre-configured set of trust anchors/root CAs. If you mean that the
signature validation typically runs from leaf certificate up to root rather
than vice-versa, then yes that is sub-optimal. Believe me, plenty of people
have criticised TLS certificate authentication! See for example Colm
MacCárthaigh’s very astute observations of the problems of mTLS (I summarise
them in [1]).
If you mean specifically OAuth certificate-bound access tokens, where indeed
the certificate authentication occurs at the transport layer and only later is
trust established via the x5t#S256 claim, then I agree that this is also not
great. However, there are mitigating factors in that case:
* You can also establish trust at the TLS layer by requiring a certificate
issued by a known CA, so the x5t check is an additional constraint, after trust
is already established.
* The access token that provides the x5t claim is validated independently of
the certificate(s) and trust is established in it before the x5t claim is used.
You do not have to parse the client certificate to discover the access token.
This is in contrast to EPOP where implementors have to parse a complex token
structure (potentially containing missing claims, duplicate claims, charset
mixup issues, etc etc) to extract information to validate the very token they
are trying to establish trust in. Yes, JSON is a complex format [2].
> 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.
But again, step 8 is optional! "If ntk is present [...]". So, as an attacker,
can I simply omit this claim and bypass the check? Years of alg:none issues in
JWTs suggests I almost certainly will be able to somewhere. Or can I provide
two such claims and count on the verification code using one of them while
backend code uses another? Again, years of parser mismatch vulnerabilities,
charset mismatch vulnerabilities, etc suggests that probably yes, this will be
something that will happen in practice.
>
> 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.
Key possession of a self-asserted key is only really useful in registration
flows to prevent unknown key-share attacks.
> 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.
Except when the nested credential is an EPOP, in which case the same
self-signed validation steps are used and no external source of trust is ever
established. Again, there are conditional steps here based on what kind of
element ends up in an ntk claim that is entirely under attacker control. How
does a validator determine what type of token is being used? Introspection of
that token?
If you want to do this, then you need a lot more guidance to implementors on
exactly how they determine which type of token to expect and when to allow the
claim to be absent entirely. How does an EPOP library author ensure that there
is never a mixup between these cases? The spec needs to be very clear on that.
>
> 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.
Again, the interpretation of a critical security claim is conditional on
context. If you want to use the same token format for all three flows, I
strongly suggest having distinct claims for these three cases, but that only
solves some of the issues.
>
> 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.
My views on DPoP are recorded in the JOSE mailing list archives. I think
aspects of the design we ended up with are less than ideal, but that is the
nature of a consensus-based decision making process. Other concerns prevailed.
EPOP should stand on its own, not compound design tradeoffs of the past in new
contexts.
[1]:
https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-is-more-interesting-than-you-might-think/
[2]: https://seriot.ch/security/parsing_json.html
-- Neil
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
