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.
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. Regards Ashwin Ambekar On Tue, May 19, 2026 at 3:14 AM Gabriel Corona <[email protected]> wrote: > Hi Ashwin > >> The ~ serialization is therefore tightly coupled to the SD-JWT >> disclosure/presentation processing model. >> > It would be possible to generalize this syntax for other > proof-of-possession tokens. For example, we could extend DPoP by allowing > joigning the JWT token and the DPoP proof JWT as : <jwt>~<dpop>. This would > make it possible to use DPoP in non-HTTP context without introducing > another proof-of-possesion token format. > >> 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. >> > I agree that the downside of the "~" format is that it introduces a new > parsing logic. > > On the other hand it reduces the base64-url expansion by avoiding nesting > tokens and can reuse existing token formats. > > Countersignatures are a related use case where nesting the base token > would be a bad idea because we might want to join multiple > countersignatures to the same base token (without sending the base token > multiple times). > > Gabriel > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
