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]
