Hi Joe, Thanks for the thoughtful feedback — apologies for the delayed reply.
You're right that the enveloped approach carries a size cost, and I want to address both the *why* and the *how much*. Why enveloped rather than detached? The primary motivation is transport agnosticism and intermediary transparency. DPoP's detached proof requires two coordinated headers (Authorization: DPoP + DPoP: <proof>) that must travel together through every hop — API gateways, service-mesh sidecars, and reverse proxies. A single intermediary that strips non-standard headers silently breaks the proof-of-possession guarantee for the entire request chain. By enveloping the proof inside the token, EPOP reduces this to a single Authorization: EPOP header that propagates unchanged through any infrastructure that forwards the Authorization header. This also directly enables non-HTTP transports (MQTT, Kafka, gRPC, SASL) where there is no second-header channel at all. Size tradeoffs I've added a Performance Implications section with concrete numbers. The overhead varies significantly by algorithm: - RS256: ~14% size increase (10% for HTTP 2 due to compression) over a detached-signature approach (the JWK in the EPOP header dominates — RSA public keys are ~256 bytes) - ES256 (P-256)/Ed25519: ~4% overhead - Opaque tokens: For opaque access tokens the enveloped form can actually be *smaller* since the token itself is shorter than a JWT. The draft recommends Ed25519/EdDSA for this reason (§10.9). Thanks for bringing this up and giving me the opportunity to update and enhance the draft. I have acknowledged this in the latest draft here: https://datatracker.ietf.org/doc/draft-ambekar-oauth-epop/01/ Regards Ashwin On Tue, May 19, 2026 at 10:08 AM Joe DeCock <[email protected]> wrote: > I would also appreciate if you could talk more about the design of the > cnonce. It seems like it is meant to replace the server nonce in DPoP, but > I don't understand how it can accomplish that. As I understand it, the > purpose of DPoP's server nonce is to prevent pre-generation attacks. It can > do that because the value of the server nonce is unpredictable. In > contrast, EPOP's cnonce is entirely deterministic. It seems like cnonce > isn't really meant to prevent pre-generation attacks. But if that's the > case, could you simplify the protocol by removing it entirely, since you > already have iat for time-bounding the token, and jti for replay detection? > > Thanks, > Joe > > On Mon, May 18, 2026 at 6:02 PM Joe DeCock <[email protected]> wrote: > >> Hi Ashwin, >> >> I think this is an interesting idea. Applying sender constraints without >> being tied to http is clearly a real problem. >> >> I'd be curious to hear more from you about the tradeoffs you considered >> when designing EPOP and why you made the decisions you did. For example, my >> intuition is that the enveloped approach results in larger data structures >> compared to a detached signature. Did you consider a design that keeps the >> detached signatures of DPoP? >> >> Thanks for your work on this draft. >> >> Joe DeCock >> >> >> On Sat, May 16, 2026 at 9:14 PM Ashwin Ambekar <[email protected]> wrote: >> >>> Hi all, >>> >>> I've submitted an initial Internet-Draft for a new OAuth 2.0 token >>> profile called Enveloped Proof of Possession (EPOP): >>> >>> https://datatracker.ietf.org/doc/draft-ambekar-oauth-epop/ >>> >>> ## What EPOP introduces >>> >>> EPOP defines a single unified token type that carries both the >>> credential (authorization code, access token, or refresh token) and its >>> cryptographic proof of possession as an inseparable envelope. This >>> eliminates the split between token issuance and proof construction that >>> exists in current mechanisms, and brings the following properties: >>> >>> 1. **Unified credential + proof token** — The credential and its PoP >>> proof are bound together at issuance into a single JWT envelope, >>> cryptographically tied to the client's key pair. Possession of the token >>> alone is insufficient to use it. >>> >>> 2. **Transport-agnostic proof of possession** — EPOP proof validation >>> does not depend on HTTP request parameters, making it applicable uniformly >>> across HTTP and non-HTTP transports: MQTT, Kafka, gRPC, SASL, and emerging >>> agentic protocols such as MCP. >>> >>> 3. **Extended PoP support for RFC 7628 (SASL/OAuth)** — EPOP provides a >>> concrete proof-of-possession mechanism for SASL-based OAuth flows defined >>> in RFC 7628, which currently lacks a sender-constraining profile. >>> >>> 4. **Client-derived nonce (cnonce)** — EPOP introduces an >>> offline-derived client nonce computed deterministically from the client's >>> private key and token material. This eliminates the server-issued nonce >>> round-trip required by existing mechanisms, enabling stateless proof >>> validation at the resource server — critical for high-throughput and >>> constrained deployments. >>> >>> The draft also covers atomic key rotation, discovery metadata >>> extensions, and security considerations for replay prevention and token >>> substitution across all supported transports. >>> >>> ## Seeking feedback on >>> >>> - Whether the unified envelope model introduces any token substitution >>> or cross-credential attack surface not addressed in Section 10. >>> - Soundness of the cnonce derivation and replay window model. >>> - Operator and implementer perspectives, particularly for non-HTTP >>> deployments. >>> - Any overlap with active WG drafts I should reference or reconcile >>> against. >>> >>> Source and issue tracker: https://github.com/asambeka/epop >>> >>> All review, critique, and collaboration interest welcome. >>> >>> Thanks, >>> Ashwin Ambekar >>> eBay >>> _______________________________________________ >>> 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]
