Hi Gabriel, Thanks — that is a very useful observation.
I agree that, at a surface level, the SD-JWT presentation syntax: <Issuer-signed JWT>~<KB-JWT> captures an important idea: combining a credential with a proof-of-possession artifact in a compact presentation form. That said, I think there are a few reasons why directly reusing the SD-JWT syntax outside the SD-JWT presentation model may not map cleanly to OAuth sender-constrained access token use cases. In SD-JWT, the KB-JWT is fundamentally a detached presentation proof: - it commits to a disclosure set via sd_hash - it binds to a verifier via aud - and it depends on a verifier-provided nonce The ~ serialization is therefore tightly coupled to the SD-JWT disclosure/presentation processing model. In contrast, in the OAuth sender-constraining case, the requirements are somewhat different: - the proof often needs to bind to request context (resource + method) - deployments may require offline proof generation (no verifier nonce round-trip) - and the credential/proof pair ideally survives intermediary forwarding as a single inseparable object One consequence is that EPOP treats the proof and credential as a single signed envelope, rather than two correlated artifacts linked externally by presentation syntax. The nested-token (ntk) approach was intended to preserve standard JWT processing semantics while avoiding special parsing logic around ~-delimited compound objects. So I think the two models are conceptually related, but optimized for different layers: - SD-JWT KB: holder-binding for selective disclosure credential presentation - EPOP: sender-constraining for OAuth/API authorization across transports That said, I do think there is value in aligning terminology and conceptual models where possible, and your point about reuse is well taken. Thanks again for raising this. I have captured detailed analysis of this draft with RFC 9901 here: https://github.com/asambeka/epop/blob/main/AnalysisWithRFC9901.md Best, Ashwin On Sun, May 17, 2026 at 1:26 AM Gabriel Corona <[email protected]> wrote: > Le 17/05/2026 à 04:08, Ashwin Ambekar a écrit : > > EPOP defines a single unified token type that carries both the > > credential (authorization code, access token, or refresh token) and its > > cryptographic proof of possessio > > For what its worth, SD-JWT [1] already has a mechanism for associating a > key binding proof of possession to a JWT in a single token: > > <Issuer-signed JWT>~<KB-JWT> > > Would it make sense, to reuse this syntax in other contexts? > > [1] https://datatracker.ietf.org/doc/html/rfc9901 > > Regards, > > Gabriel > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Regards Ashwin Ambekar
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
