> On 20 May 2026, at 19:52, Ashwin Ambekar <[email protected]> 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 _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
