]> eBay

ambekar@gmail.com aambekar@ebay.com

Security Web Authorization Protocol EPOP oauth proof-of-possession sender-constrained token binding jwt profile token profile This specification defines a profile for OAuth 2.0 sender-constrained credentials in which access tokens and refresh tokens are cryptographically bound to the client's private key as a single inseparable envelope. Authorization code flows are also covered: the client declares its public key binding via cnf.jkt in the EPOP token presented at the token endpoint, ensuring the authorization code can only be exchanged by the key-holding client; the code itself travels as the standard code form parameter. Unlike existing mechanisms, EPOP provides proof-of-possession uniformly across both JWT and opaque access tokens, and across HTTP and non-HTTP transports. The profile extends sender-constraining beyond HTTP to non-HTTP transports including MQTT, Kafka, the Model Context Protocol (MCP), gRPC, and SASL-based protocols such as those defined in . It introduces atomic proof-of-possession key rotation, enabling clients to rotate key pairs without disrupting active sessions, and an offline-derived client nonce (cnonce) that eliminates the server-issued nonce round-trip required by existing mechanisms — enabling stateless proof validation critical for non-HTTP and high-throughput deployments. Authorization servers, resource servers, and clients from different vendors can implement this profile interoperably. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAuth 2.0 access tokens are bearer tokens by default: any party in possession of a token can use it, regardless of whether that party is the legitimate client to which the token was issued. This property makes token theft a practical attack — intercepted tokens can be replayed without further credential material. Sender-constraining mechanisms address this by cryptographically binding a token to the client's key pair so that possession of the token alone is insufficient to use it. Demonstrating Proof of Possession (DPoP) introduced sender-constraining for HTTP-based OAuth flows. However, DPoP relies on HTTP-specific request parameters (htm, htu) and a server-issued nonce mechanism that requires an additional round-trip and imposes per-client nonce state management on servers — making it unsuitable for non-HTTP transports such as MQTT, Kafka, gRPC, and SASL-based protocols. DPoP's ath claim binds opaque access tokens on HTTP, but provides no sender-constraining path for opaque tokens on non-HTTP transports. No existing specification provides an interoperable sender-constraining profile that operates uniformly across both JWT and opaque access tokens, and across both HTTP and non-HTTP transports. Opaque access tokens are widely deployed in production environments for their revocability, privacy properties, and compact size. Selective disclosure mechanisms such as SD-JWT () require JWT structure and cannot be applied to opaque tokens. No existing sender-constraining mechanism addresses opaque access tokens outside of HTTP. This leaves a broad class of production deployments — those using opaque tokens with Kafka, MQTT, gRPC, or SASL-based protocols — without any interoperable proof-of-possession mechanism. A further deployment challenge with DPoP is the requirement to propagate two distinct HTTP headers — Authorization: DPoP <token> and DPoP: <proof> — as an inseparable pair through every layer of a distributed system. API gateways, reverse proxies, and service-mesh sidecars must each be updated to recognize and forward the DPoP header; many intermediaries strip non-standard headers by default. Every resource server onboarded to DPoP must separately implement dual-header awareness and proof validation. A single hop that discards the DPoP header silently invalidates the proof-of-possession guarantee for the entire request chain, creating a widespread integration burden across heterogeneous microservice deployments. This document defines the Enveloped Proof of Possession (EPOP) profile for OAuth 2.0 credentials. For token-based flows, the OAuth credential — access token or refresh token — is nested within the ntk (Nested Token) claim () of a signed JSON Web Token (JWT) envelope; the credential and the proof of possession are a single, inseparable cryptographic object signed with the client's private key. In authorization code flows, the code travels as the standard code form parameter while the EPOP token carries only cnf.jkt, declaring the client's key binding before the AS issues any tokens. The ntk claim accommodates both JWT and opaque access tokens using the same envelope and validation path, providing uniform proof-of-possession regardless of token format. The profile introduces a protocol-neutral rctx (Request Context) claim () that replaces the HTTP-specific htm/htu claims of DPoP, enabling EPOP tokens to operate over any transport without protocol-specific adaptation. An offline-derived client nonce (cnonce) () computed from public inputs eliminates the server-issued nonce round-trip required by , enabling stateless proof validation particularly suited to non-HTTP and high-throughput transports. The profile further defines atomic proof-of-possession key rotation, in which a client introduces a new key pair during a token refresh without disrupting the active session, and extends coverage to the full OAuth token lifecycle including token revocation and token exchange. Together, these properties make EPOP the first sender-constraining profile to cover all four combinations: JWT tokens over HTTP, opaque tokens over HTTP, JWT tokens over non-HTTP transports, and opaque tokens over non-HTTP transports. For SASL-based protocols, this document defines OAUTHEPOP, a new SASL mechanism extending with sender-constraining support. All behaviors defined in remain in effect; this document adds only the EPOP-specific authentication type and key binding verification.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Conformance requirements for EPOP-issuing Authorization Servers, EPOP-validating Resource Servers, and EPOP Clients are summarized in . The following terms are used throughout this document:

EPOP Token:

A signed JWT () with typ: epop+jwt, signed by the client's private key. Contains an OAuth 2.0 credential in the ntk claim when used for resource access, token refresh, token revocation, or token exchange. In authorization code exchange and PAR flows, contains only cnf.jkt for key binding; the authorization code travels as the standard code form parameter and is never embedded in ntk.

Nested Token (ntk):

The OAuth 2.0 credential (access token, refresh token, or another EPOP token for key rotation) embedded inside an EPOP token's payload. Not present in EPOP tokens used for authorization code exchange.

Request Context (rctx):

A JSON object in the EPOP payload that identifies the target resource and protocol action, replacing the HTTP-specific htm/htu claims of DPoP.

Client Nonce (cnonce):

An HMAC value derived offline from the client's public key, an optional server-supplied seed, and a time-step counter, providing replay resistance without server-issued nonce state.

Authorization Server (AS):

A server that issues OAuth 2.0 tokens to clients. As defined in .

Resource Server (RS):

A server that hosts protected resources and accepts OAuth 2.0 tokens. As defined in .

Client:

An application that requests OAuth 2.0 tokens and uses them to access protected resources. As defined in .

JWK Thumbprint:

The SHA-256 thumbprint of a JSON Web Key, computed as defined in .

Conformance This specification defines normative requirements for three conformance roles:

EPOP-issuing Authorization Server:

An AS that issues EPOP-bound tokens MUST bind all issued tokens to the client's public key via cnf.jkt, MUST validate EPOP tokens presented at the token endpoint per , and MUST publish EPOP capability metadata per .

EPOP-validating Resource Server:

An RS that accepts EPOP tokens MUST verify the outer envelope signature, MUST validate rctx members when rctx is present, and MUST verify cnf.jkt against the key in the EPOP token header per .

EPOP Client:

A client producing EPOP tokens MUST sign each token with the private key whose public component appears in the EPOP token header, MUST NOT reuse jti values, and MUST derive cnonce per when the AS requires it.

EPOP Token Profile An EPOP token is a signed JWT () with typ: epop+jwt.

Header

typ

REQUIRED. MUST be epop+jwt.

alg

REQUIRED. Asymmetric signature algorithm. Edwards curve algorithms are RECOMMENDED for their superior security, performance, and payload compactness; see . Symmetric algorithms (HS*) and none MUST NOT be used.

jwk

REQUIRED. The client's public key as a JWK (). MUST NOT contain private key material.

Example header: " } } ]]>

Payload

jti

REQUIRED. Unique JWT ID with high entropy (see ). Servers MUST maintain a replay cache keyed on jti.

iat

REQUIRED. Issued-at Unix timestamp. Servers MUST reject tokens older than the server-defined maximum EPOP lifetime or issued in the future beyond clock skew. EPOP tokens MUST be short-lived, per-request credentials. The exp claim MUST NOT be included; the validity window is controlled entirely by the server's iat-based lifetime policy and, when cnonce is required, by epop_cnonce_step_seconds.

ntk

CONDITIONAL. The nested OAuth 2.0 credential. REQUIRED for resource access, token refresh, token revocation, and introspection. OMITTED in authorization code exchange flows; the authorization code travels as the standard code form parameter. JWT credentials (access tokens, refresh tokens, and inner EPOP tokens for key rotation) are encoded as compact-serialized JWTs; opaque credentials are Base64URL-encoded opaque strings.

cnonce

RECOMMENDED. Offline-derived client nonce (see ). MUST be included when the server publishes epop_cnonce_required: true.

rctx

OPTIONAL. Request context object. When present, all recognized members MUST be validated by the server. Unrecognized members MUST be ignored. Future rctx member names will be registered in the EPOP Request Context Members registry ().

rctx.res

OPTIONAL. URI or URN of the target resource or endpoint.

rctx.method

RECOMMENDED. Protocol action string. Case-insensitive for HTTP methods; case-sensitive otherwise.

rctx.id

OPTIONAL. Client-generated correlation ID for async or multiplexed protocols.

cnf.jkt

CONDITIONAL. SHA-256 JWK Thumbprint () of the client's public key. REQUIRED in authorization code exchange and in the inner envelope of a key rotation request. SHOULD be omitted on routine resource access and simple refresh where the key is already bound to the token.

Example payload (resource access): ", "cnonce": "", "rctx": { "res": "https://api.example.com/orders", "method": "GET" } } ]]>

Issuing and Constructing EPOP Tokens The client MUST have an asymmetric key pair (private key held exclusively by the client; public key embedded in every EPOP header), a reliable source of high-entropy identifiers for jti, and a trusted clock for iat. An EPOP token is a JWS () signed with the client's private key, carrying the header and payload claims defined in and . The compact serialization is transmitted as:

• Token endpoint and PAR: the epop form parameter in the POST body, preserving the Authorization header for client authentication.
• Resource server: Authorization: EPOP <compact-serialized-epop-token> per .

When the AS issues tokens in response to a valid EPOP request, it MUST bind the issued credential to the client's public key by including cnf.jkt — the SHA-256 JWK Thumbprint () of the EPOP token's jwk — in the response. For opaque tokens, the AS MUST record this binding server-side for use by the introspection endpoint. The AS MUST NOT issue EPOP-bound tokens unless the EPOP token has been successfully validated per . The token endpoint response MUST include "token_type": "EPOP" for all EPOP-bound credentials, per Section 5.1. This signals to the client that the issued token must be presented using the Authorization: EPOP scheme at the RS.

Validating an EPOP Token To validate an EPOP token, the receiving server MUST ensure all of the following:

1. The typ header value is epop+jwt.
2. The jwk header is a valid asymmetric public key with no private key material.
3. The JWS signature verifies with the public key in jwk.
4. The iat is within an acceptable window, accounting for clock skew and the server's maximum EPOP lifetime policy.
5. The jti has not been seen before; record it and reject any future token presenting the same value.
6. If the server requires cnonce (i.e., epop_cnonce_required is true in its discovery document), the cnonce claim MUST be present. If cnonce is present, it MUST be valid for the current time-step (see ).
7. If rctx is present, its members match the current request context; unrecognized members MUST be ignored.
8. If ntk is present, sha256(jwk) MUST equal cnf.jkt from the nested credential (see ). This check MUST be performed after steps 1–3 pass.

These checks apply at both the AS (token endpoint, PAR) and RS (resource access). The server MUST reject the request with an appropriate error (see ) if any check fails.

Error Responses When a server rejects an EPOP token, it MUST respond as follows. At the token endpoint (AS), validation failures MUST result in an HTTP 400 response with an OAuth error body per Section 5.2. The error value MUST be invalid_request for structural failures (e.g., missing typ, invalid jwk format) and invalid_grant for credential failures (e.g., expired iat, replayed jti, invalid cnonce, cnf.jkt mismatch). At the resource server, validation failures MUST result in an HTTP 401 response with a WWW-Authenticate challenge using the EPOP scheme per : The error parameter MUST be invalid_token for any EPOP envelope or key binding failure. Servers MAY include error_description with a human-readable explanation. Servers MUST NOT reveal which specific validation step failed, as such information could aid an attacker.

Nested Credential Validation When ntk is present and the outer envelope has passed steps 1–7, the server MUST perform the key binding check (step 8) and then validate the nested credential:

• JWT (access or refresh token): verify signature, iss, exp, aud, and scopes.
• Opaque token: introspect with the AS per .
• Inner EPOP (key rotation): apply steps 1–8 to the inner envelope; cnf.jkt in the inner envelope identifies the new key.

The key binding check requires sha256(outer jwk) == cnf.jkt from the nested credential. If this check fails, the server MUST reject the request with invalid_token.

OAuth 2.0 Flows with EPOP

Authorization Server Flows

OAuth 2.0 Protocol Changes Summary

Element	Change	Impacted Flows
grant_type	New values: epop_code_grant, epop_refresh_token	Authorization code exchange, token refresh
epop	New form parameter; carries compact-serialized EPOP token	Authorization code exchange, token refresh, PAR
actor_token_type	New values: urn:ietf:params:oauth:token-type:epop_access_token, urn:ietf:params:oauth:token-type:epop_refresh_token	Token exchange
token_type_hint	New value: epop_token	Token revocation, token introspection
Issued token response	AS MUST include cnf.jkt binding in all issued tokens	All grant flows
PKCE (code_challenge)	Elevated from RECOMMENDED to REQUIRED	Authorization code exchange, PAR

Authorization Code Flow with PKCE PKCE () is REQUIRED in all EPOP authorization code flows. PKCE and EPOP protect complementary attack surfaces: PKCE binds the authorization request to the token request; EPOP binds the authorization code to the client's key pair. Without PKCE, an attacker who intercepts the authorization code could generate their own key pair and wrap the code in a valid EPOP token signed with their key. Together they provide end-to-end chain of trust from the authorization request through token issuance (see ).

Authorization Code Flow with EPOP and PKCE | | | (code_challenge, PKCE) | | | | | |<-- 2. Authorization Code ----| | | | | |-- 3. Token Request (POST) -->| | | grant_type=epop_code_grant | (abbreviated; full URN) | | epop=| | | + code, code_verifier | | | (form parameters) | | | | | |<-- 4. Access Token ----------| | | (cnf.jkt bound to key) | | | | | |-- 5. Resource Request ---------------------------------->| | Authorization: EPOP | | | | |<-- 6. Protected Response --------------------------------| ]]>

Token request (Step 3): Decoded EPOP token payload for this request (cnf.jkt declares the client's key binding; ntk is absent because the authorization code travels as the code form parameter per standard OAuth 2.0): Token endpoint response (Step 4): ", "token_type": "EPOP", "expires_in": 3600 } ]]> The issued access token returned by the AS carries the cnf.jkt binding:

Token Refresh Flow The client wraps the refresh token in the ntk claim of an EPOP token and submits it using the epop_refresh_token grant type: ]]>

Simple Refresh The EPOP token wraps the refresh token directly in ntk: ", "iat": "", "ntk": "", "rctx": { "res": "https://as.example.com/token", "method": "POST" } } ]]> After standard EPOP validation (), the AS validates the nested refresh token. For an opaque token, the AS looks it up in the server-side store, verifies it is not revoked or expired, and confirms the associated key matches sha256(outer jwk). For a JWT refresh token, the AS verifies the signature, iss, exp, and jti, then confirms cnf.jkt == sha256(outer jwk).

Key Rotation Refresh Key rotation uses a two-layer structure. The inner envelope is a Simple Refresh EPOP token (signed with the OLD key) with one addition: cnf.jkt set to the thumbprint of the NEW key. The outer envelope, signed with the NEW key, carries the compact-serialized inner EPOP token in ntk: ", "iat": "", "ntk": "" } ]]> Standard EPOP validation () applies to both envelopes. Beyond that, the AS verifies the key handoff chain: sha256(inner jwk) MUST match the key previously bound to the refresh token, and sha256(outer jwk) MUST equal inner cnf.jkt. On success, the AS issues new tokens bound to sha256(outer jwk), atomically updates the server-side key binding, and revokes the old key for this session. The old key's authorization of the new key's introduction, combined with the new key's simultaneous proof of possession, provides a non-repudiable chain of custody.

Token Introspection Token introspection () for EPOP tokens supports two modes.

Mode 1: Inner Token Introspection The caller extracts the access token from the ntk claim of the received EPOP token and submits it to the introspection endpoint with the appropriate token_type_hint (e.g., access_token): token= &token_type_hint=access_token ]]> The introspection response includes cnf.jkt. The caller MUST verify that sha256(EPOP token signing key) equals the cnf.jkt returned in the response. This check confirms that the EPOP envelope was signed by the key legitimately bound to the nested token.

Mode 2: Full EPOP Token Introspection The caller sends the entire EPOP token to the introspection endpoint with token_type_hint=epop_token: token= &token_type_hint=epop_token ]]> The AS validates the EPOP envelope signature, extracts the credential from ntk, and validates it. The AS MUST verify that sha256(EPOP token signing key) equals the cnf.jkt in the nested token before returning a response. This check prevents a caller from presenting a valid EPOP envelope wrapping a token not bound to that key. In both modes the introspection response includes cnf.jkt. For opaque tokens, cnf.jkt is the server-side registered client EPOP public key; for JWT tokens it is extracted from the token's own cnf.jkt claim. The token_type field reflects the type of the inner access token in ntk, not the outer EPOP envelope.

Token Exchange Clients can exchange an EPOP-wrapped token for a new token using the token exchange framework (). In this flow the client is the actor — it acts on behalf of a subject and proves its identity by presenting the EPOP token as the actor_token. The subject_token carries the token being exchanged on behalf of the subject; subject_token_type identifies its format. The actor_token_type identifies the EPOP token format using the epop_access_token token type identifier (): &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token &actor_token= &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aepop_access_token &requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aepop_access_token ]]> The AS MUST validate the EPOP envelope per before processing the exchange. The AS MUST also validate the subject_token independently per its token type. The AS issues a new EPOP-wrapped access token bound to the same client public key, or to a new key if the exchange request includes key rotation. Token exchange response: ", "issued_token_type": "urn:ietf:params:oauth:token-type:epop_access_token", "token_type": "EPOP", "expires_in": 3600 } ]]> The issued access token carries cnf.jkt bound to the client's public key, as in all EPOP flows.

Token Revocation Clients revoke EPOP-wrapped tokens using the token revocation framework (). The client constructs and signs the EPOP token containing the credential to be revoked, then submits it as the token parameter with a token_type_hint identifying the credential type: &token_type_hint=epop_token ]]> The AS MUST validate the EPOP envelope per before processing revocation. The token_type_hint value MUST be epop_token (). The requirement that the client construct and sign the EPOP envelope provides proof-of-possession on revocation: an attacker who captured a token but does not hold the corresponding private key cannot revoke it. This is a deliberate security improvement over plain RFC 7009 revocation, where any party holding the raw token value can submit a revocation request.

Pushed Authorization Requests For PAR (), the client MAY declare its public key fingerprint at the PAR endpoint to pre-bind the authorization code to the client's key before the browser redirect. The client includes the EPOP token as the epop form parameter — with cnf.jkt and rctx but no ntk — alongside the standard PAR request parameters. The Authorization header carries client authentication as usual. PKCE parameters (code_challenge, code_challenge_method) MUST be included in the PAR request (this specification elevates PKCE from RECOMMENDED in to REQUIRED in all EPOP flows); the subsequent token endpoint request MUST include code_verifier. EPOP token payload for the PAR request: ", "iat": "", "cnf": { "jkt": "" }, "rctx": { "res": "https://as.example.com/par", "method": "POST" } } ]]> HTTP request: ]]> The AS verifies the EPOP signature, extracts cnf.jkt, and records it against the request_uri it returns. Once a cnf.jkt is registered via PAR, that key binding is final for the lifetime of the resulting authorization code. If the EPOP token presented at the token endpoint declares a different cnf.jkt than the one recorded at the PAR endpoint, the AS MUST reject the request.

Unsupported Flows

Client Credentials Flow Client credentials flow is not covered by this specification.

Authorization Request Key Binding Not Supported Binding a public key thumbprint inside the authorization request URL (analogous to dpop_jkt in Section 10) is not supported; see for the security rationale.

Resource Server Flows

Resource Access The client sends the EPOP token in the HTTP Authorization header using the EPOP authentication scheme (). No Authorization: Bearer header is used. EPOP token payload: ", "rctx": { "res": "https://api.example.com/orders", "method": "GET" } } ]]> HTTP request: ]]> The RS verifies the outer envelope, then extracts and validates the access token from ntk as defined in .

Non-HTTP and Agentic Protocols The EPOP token structure is identical for non-HTTP protocols; only rctx values differ. The rctx.res field accommodates any URI or URN:

Protocol	rctx.res	rctx.method
HTTPS	https://api.example.com/orders	GET
MQTT	urn:mqtt:broker:sensors/temperature	PUBLISH
MCP	urn:mcp:server:filesystem	tools/call
Kafka	urn:kafka:cluster:orders-topic	Produce
gRPC	urn:grpc:service:helloworld.Greeter	SayHello

The rctx.id field lets the server correlate the EPOP token with an asynchronous response — critical in multiplexed or streaming protocols where request/response pairs are not strictly sequential: ", "rctx": { "res": "urn:mcp:server:filesystem", "method": "tools/call", "id": "req_5521" } } ]]>

SASL Integration This section extends to support Enveloped Proof of Possession. All behaviors defined in — including the GS2 () message structure, connection-establishment scope, server error challenge format, and error handling — apply to OAUTHEPOP unless explicitly stated otherwise in this section.

OAUTHEPOP Mechanism OAUTHEPOP is a new SASL mechanism following the structure of Section 3. Implementors should note that EPOP compact serializations (header, payload, and signature) may be significantly larger than a plain bearer token; SASL implementations MUST support initial client response buffers large enough to carry the full compact-serialized EPOP JWT. It introduces EPOP as the OAuth authentication type for the auth field of the GS2 initial client response. The auth field for OAUTHEPOP is defined as: where epop-token is the compact-serialized EPOP JWT as defined in and kvsep is %x01 per . All other fields in the GS2 initial client response (host, port, GS2 header, final kvsep) are unchanged from Section 3. Example initial client response (using %x01 represented as <SOH>): auth=EPOP host=mail.example.comport=993 ]]>

OAUTHBEARER Backward Compatibility Servers advertising OAUTHBEARER MAY also accept EPOP tokens by recognizing auth=EPOP in the initial client response. When a server receives auth=EPOP over the OAUTHBEARER mechanism, it MUST treat the value as a compact-serialized EPOP JWT and apply the key binding check defined in . The server determines whether the nested access token in ntk is EPOP-bound as follows:

• Opaque nested access token: The server calls token introspection (). If the introspection response includes cnf.jkt, the token is EPOP-bound; the server MUST verify sha256(outer jwk) == cnf.jkt before accepting the connection.
• JWT nested access token: The server inspects the typ claim of the access token extracted from ntk. If typ == "epop+jwt", the token is EPOP-bound; the server MUST apply the same key binding check.

Servers SHOULD advertise OAUTHEPOP in SASL capability responses when EPOP is supported and SHOULD list it ahead of OAUTHBEARER. Clients that support EPOP MUST use OAUTHEPOP when the server advertises it.

UserInfo Endpoint The client presents an EPOP token wrapping the access token at the UserInfo endpoint: ", "iat": "", "ntk": "", "rctx": { "res": "https://as.example.com/userinfo", "method": "GET" } } ]]> ]]> The AS validates the EPOP token per , verifying rctx.res matches its UserInfo endpoint URI, then returns UserInfo claims.

Resource Server Binding

Key Binding Enforcement Every JWT access token issued under EPOP carries a cnf.jkt claim — the SHA-256 thumbprint of the client's EPOP public key. When the RS receives an EPOP-wrapped request:

1. It verifies the outer EPOP signature using the jwk embedded in the header.
2. It extracts the access token from ntk and validates it (signature, exp, aud, scopes).
3. It computes sha256(outer jwk header key) and compares it to cnf.jkt inside the access token.

If the two values differ, the RS MUST reject the request with invalid_token. This check prevents an attacker from wrapping a stolen access token in their own EPOP envelope.

Early-Exit Pattern The rctx check ( Step 7) SHOULD occur before nested credential validation (). If rctx.res or rctx.method does not match the current request, the RS SHOULD reject immediately without decoding or verifying the access token. This is the primary defense against replay of an EPOP token from one endpoint at another within the token's short validity window.

RS Handling of Opaque Access Tokens When the access token in ntk is opaque, the RS MUST introspect the received EPOP token with the AS (), passing it as the token parameter with token_type_hint=epop_token so the AS can validate the envelope and extract the inner token: token= &token_type_hint=epop_token ]]> The introspection response includes the cnf.jkt claim:

RS State Management for Opaque Tokens The RS MUST NOT cache introspection results beyond the EPOP token's validity window. Since EPOP tokens are very short duration per-request credentials, a stale introspection cache could cause the RS to validate a post-rotation request against the pre-rotation key. When the client performs key rotation (), the AS MUST atomically update its server-side registry before issuing any new tokens. Introspection responses for access tokens issued after rotation MUST reflect the new client EPOP public key.

Scenario	RS Obligation
Opaque access token, no caching	Call introspection per request; use returned cnf.jkt for binding check
Opaque access token, cached introspection	Cache MUST expire at or before the EPOP token validity window; MUST NOT reuse across key rotation
Key mismatch detected	Reject with invalid_token; MUST NOT fall back to a previously cached key
Opaque refresh token key rotation (AS-side)	AS MUST atomically update server-side key registration; partial update MUST NOT be possible

Client Nonce (cnonce)

Overview cnonce is an offline-derived nonce that time-bounds each EPOP token to a discrete step window. Unlike the DPoP server-issued nonce ( Section 8), it requires no server round-trip and carries no server-side nonce state, making it particularly suited to non-HTTP transports and high-throughput deployments. cnonce reduces the replay opportunity within a window; the jti replay cache ( Step 5) remains the primary replay prevention mechanism and MUST be maintained regardless.

Notation The following notation is used in this section:

SPKI

DER-encoded SubjectPublicKeyInfo of the client public key in the EPOP token header.

X

Time-step duration in seconds, taken from epop_cnonce_step_seconds.

seed

Optional 32-byte deployment seed from epop_cnonce_seed. When absent, treated as the empty octet string.

HKDF-SHA256(ikm, salt, info, len)

HKDF with SHA-256 per , producing len octets.

HMAC-SHA256(key, data)

HMAC with SHA-256 per .

BASE64URL(octets)

Base64url encoding without padding per Section 5.

UTF8(str)

UTF-8 encoding of string str per .

UINT64BE(n)

8-octet big-endian encoding of integer n.

||

Octet string concatenation.

Computation The time-step counter is: The per-client key material is derived once per key pair and re-derived on seed rotation: When seed is absent, ikm = SPKI. The optional seed scopes derivation per deployment so that cnonce values from clients under different seeds are non-interchangeable. The cnonce value is: where jti is the EPOP token's own unique identifier.

Verification The server (AS or RS) derives key_material identically and verifies: for any t ∈ {T-1, T, T+1}. This window absorbs clock skew of up to one step. If no value of t satisfies the equality, the server MUST reject the token. A cnonce satisfying the time-window check but carrying a replayed jti is caught by the replay cache ( Step 5). When epop_cnonce_seed is rotated, the server MUST update epop_cnonce_seed_id simultaneously so that clients re-derive key_material.

Seed Domain Isolation The optional seed parameter scopes key_material derivation so that cnonce values produced under one seed cannot validate against a server holding a different seed. This property is most valuable when the AS and RS each hold their own independently chosen seed. Because every EPOP token is destination-bound — tied to a single server via rctx — there is no correctness requirement for the AS and RS to share a seed. Using distinct seeds provides the following security benefits:

• Cross-domain replay resistance. A cnonce computed for the AS domain cannot satisfy verification at the RS, and vice versa, even within the same time-step window. This supplements the rctx check with a cryptographic barrier at the key-derivation level.
• Independent seed rotation. Each server can rotate its seed on its own schedule without coordinating with the other, reducing operational coupling between the AS and RS.
• Blast-radius limitation. If a seed value is inadvertently exposed (e.g., via a misconfigured metadata endpoint), only the cnonce namespace of that server is affected; the other server's namespace remains intact.

Sharing a seed across the AS and RS confers none of these benefits and is NOT RECOMMENDED. Both servers SHOULD rotate epop_cnonce_seed periodically to further limit the window in which precomputed cnonce values remain valid.

Discovery Metadata Authorization Servers that support EPOP MUST publish their capabilities in the OAuth Authorization Server Metadata document (), available at /.well-known/oauth-authorization-server (or /.well-known/openid-configuration for OpenID Connect providers). Resource Servers publish EPOP capabilities in the OAuth Protected Resource Metadata document (), available at /.well-known/oauth-protected-resource.

Metadata Fields Each server publishes its own epop_cnonce_seed, epop_cnonce_seed_id, and epop_cnonce_step_seconds values independently. Clients MUST read the target server's discovery document and use the values from that document when deriving cnonce for requests to that server. Because EPOP tokens are destination-bound — each is tied to a single endpoint via rctx — the AS and RS never need to verify the same cnonce value. Using distinct seeds for the AS and RS improves security by isolating their cnonce derivation namespaces and providing stronger protection against precomputed cnonce attacks: an attacker who learns one server's seed gains no advantage against the other. AS and RS SHOULD also rotate epop_cnonce_seed periodically for further protection against precomputation; see .

epop_supported

String; AS and RS. REQUIRED when EPOP is active. Server EPOP posture: "disabled" — clients MUST NOT send EPOP tokens; "recommended" — EPOP accepted but non-EPOP requests also accepted; "required" — requests without a valid EPOP token MUST be rejected.

epop_ntk_types_supported

Array of strings; AS and RS. REQUIRED when epop_supported is not "disabled". Credential formats accepted inside ntk: "jwt" and/or "opaque".

epop_key_rotation_supported

Boolean; AS only. Default: false. When true, the server supports the two-layer EPOP key rotation flow (). Clients MUST check this field before attempting key rotation.

epop_cnonce_required

Boolean; AS and RS. Default: false. When true, the server MUST reject EPOP tokens that omit cnonce. Clients MUST include cnonce if either the AS or RS sets this to true.

epop_cnonce_step_seconds

Integer; AS and RS. REQUIRED when epop_cnonce_required is true. Time-step duration in seconds; both client and server compute T = floor(utc_now() / epop_cnonce_step_seconds). Clients use the value from the target server's discovery document. AS and RS SHOULD use the same value to simplify operational management; divergent step sizes are functionally correct but weaken the replay bound at whichever server uses the longer window.

epop_cnonce_seed

String (Base64URL, 32 bytes); AS and RS. OPTIONAL. Server-specific namespace discriminator for cnonce derivation; improves security by making cnonce values non-interchangeable across servers and limiting the blast radius of seed exposure. Not a secret. AS and RS SHOULD use distinct seeds; see . Rotated in coordination with epop_cnonce_seed_id.

epop_cnonce_seed_id

String; AS and RS. REQUIRED when epop_cnonce_seed is present; OPTIONAL otherwise. Opaque identifier for the current epop_cnonce_seed on this server. Clients MUST cache each server's discovery document keyed on this value and re-derive key_material only when it changes.

AS Metadata Example ", "epop_cnonce_seed_id": "as-seed-20260722T0600Z" } ]]>

RS Metadata Example ", "epop_cnonce_seed_id": "rs-seed-20260722T0800Z" } ]]>

Relationship to Other Specifications

RFC	Title	Relationship
	A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth	EPOP extends RFC 7628 by introducing EPOP as a new OAuth authentication type for the SASL auth field and defining OAUTHEPOP as a new SASL mechanism. All behaviors defined in RFC 7628 remain in effect; this document adds only the auth=EPOP field value and the key binding check that OAUTHBEARER servers apply when they encounter it.
	OAuth 2.0 Demonstrating Proof of Possession (DPoP)	EPOP generalizes the DPoP proof model: replaces htm/htu with rctx for protocol agnosticism; replaces the ath hash with ntk embedding so credential and proof travel as one object; extends coverage to refresh tokens and to authorization code flows via cnf.jkt key binding at the token endpoint (authorization codes travel as standard code form parameters and are never embedded in ntk); adds atomic key rotation and the offline cnonce. Additionally, DPoP's requirement to carry two coordinated HTTP headers (Authorization and DPoP) imposes a propagation burden on every intermediary and resource server in a distributed system; EPOP eliminates this by enveloping the proof inside the token, so a single Authorization header carries the inseparable credential-and-proof object through all hops without requiring middleware changes. Additionally, DPoP's ath mechanism for opaque access tokens is coupled to HTTP request parameters, leaving opaque tokens on non-HTTP transports without a sender-constraining path. EPOP's ntk claim handles opaque and JWT tokens identically across all transports.
	Proof Key for Code Exchange (PKCE)	EPOP elevates PKCE from RECOMMENDED to REQUIRED in all authorization code flows.
	OAuth 2.0 Authorization Server Metadata	EPOP adds new discovery fields to the well-known document: epop_supported, epop_ntk_types_supported, epop_key_rotation_supported, and the epop_cnonce_* family.
	JSON Web Key (JWK) Thumbprint	EPOP uses the SHA-256 JWK thumbprint (cnf.jkt) as its primary key binding primitive — embedded in every issued token and checked by the RS as its main defense against token substitution.
	OAuth 2.0 Token Introspection	EPOP extends introspection responses to include cnf.jkt. For opaque tokens the AS returns the server-side registered client EPOP public key; for JWT tokens it is extracted from the token's own claim.
	OAuth 2.0 Pushed Authorization Requests (PAR)	EPOP extends PAR to let the client declare cnf.jkt at the earliest point in the flow, pre-binding the authorization code before the browser redirect.
	HMAC-based Key Derivation Function (HKDF)	EPOP uses HKDF-SHA256 to derive a per-client key from the optional server-controlled epop_cnonce_seed and the client's public key, enabling stateless offline cnonce computation.
	Selective Disclosure for JWTs (SD-JWT)	SD-JWT provides selective disclosure of JWT claims but has no sender-constraining mechanism and requires JWT structure — it cannot be applied to opaque access tokens. EPOP is complementary: an SD-JWT credential can be carried in the EPOP ntk claim, gaining sender-constraining without modifying the SD-JWT format. A profile combining EPOP and SD-JWT is left to a future document.

Performance Considerations

Token Size EPOP consolidates the access token and the proof of possession into a single token, eliminating the separate DPoP proof header. The net effect on wire size depends on the access token format in use. The table below compares the combined size of an AT+DPoP pair against an EPOP token for representative algorithm combinations, and shows the percentage change (negative = EPOP is smaller; positive = EPOP is larger). Sizes include the full Base64url-encoded token strings as they would appear on the wire. The compressed figures approximate HTTP/2 header-compression (Huffman coding) applied to the token value. Token size comparison: AT+DPoP vs EPOP

AT Format	Proof Algorithm	AT+DPoP / EPOP Raw (B)	Raw Δ%	AT+DPoP / EPOP Compressed (B)	Compressed Δ%
Opaque	Ed25519	599 / 553	−7.7%	437 / 398	−8.9%
Opaque	RSA-256	1247 / 1201	−3.7%	918 / 880	−4.1%
JWT Ed25519	Ed25519	1030 / 1128	+9.5%	745 / 811	+8.9%
JWT Ed25519	RSA-256	1678 / 1776	+5.8%	1230 / 1291	+5.0%
JWT RSA-256	Ed25519	1288 / 1472	+14.3%	950 / 1050	+10.5%
JWT RSA-256	RSA-256	1936 / 2120	+9.5%	1429 / 1536	+7.5%

EPOP is 4–9% smaller than AT+DPoP when the access token is opaque, because eliminating the separate DPoP proof token removes its JOSE header, claims, and signature overhead. When the access token is a JWT, EPOP is 6–14% larger, as the full AT payload must be re-encoded inside the EPOP envelope; the overhead is highest with RSA keys, where large key material is effectively carried twice. Header compression (e.g., HPACK in HTTP/2) reduces the gap in all cases but does not reverse the direction of the comparison. The absolute size differences in the table (46–184 bytes uncompressed) are small relative to typical HTTP request sizes. On networks with standard MTUs (1500 bytes) or jumbo frames (9000 bytes), these differences are unlikely to cause additional TCP segment fragmentation for most requests. However, deployments on legacy or constrained networks with smaller effective MTUs, or requests already near the fragmentation boundary due to large URL paths or other headers, may see an additional packet fragment introduced in JWT AT configurations where EPOP is larger. Implementers with strict packet-budget requirements on such networks should prefer opaque access tokens with Ed25519 proofs, which yield the smallest EPOP tokens.

Computational Overhead EPOP validation replaces the two independent verification steps required for AT+DPoP (verify the access token, then verify the DPoP proof) with a single nested-token validation. The cryptographic cost depends on the algorithms chosen and is equivalent to the sum of one AT signature verification and one proof signature verification in both approaches; EPOP does not introduce additional cryptographic operations relative to AT+DPoP. Resource servers that implement the early-exit optimization described in can skip inner-token decoding when the outer EPOP signature fails, achieving better average-case performance under adversarial or malformed-token conditions.

Latency and Header Processing Because EPOP is presented as a single Authorization header value, resource servers process one token per request rather than parsing and validating two separate headers (Authorization: DPoP ... and DPoP: <proof>). This reduces per-request HTTP header parsing overhead and simplifies the validation state machine on the resource server. For deployments using token introspection, the reduction from two network-visible tokens to one also halves the number of token values the resource server must convey to the introspection endpoint per request (when full-token introspection is used; see ).

Deployment Guidance Implementers should select the EPOP deployment profile that best matches their token format:

• Opaque AT deployments gain a measurable wire-size reduction (4–9%) and simplified transport with no increase in computational cost. EPOP is the preferred choice.
• JWT AT deployments should weigh the modest size increase (6–14%) against the reduced parsing complexity and unified validation logic. For deployments where header size is a significant constraint (e.g., HTTP/1.1 without compression, constrained-device networks), issuers may consider switching to opaque access tokens or choosing compact proof algorithms (Ed25519 over RSA) to limit overhead.
• Algorithm selection has a larger impact on total token size than the choice between AT+DPoP and EPOP. RSA-based algorithms produce tokens 2–3× larger than elliptic-curve equivalents regardless of the token binding mechanism used.

Security Considerations

Token Lifetime EPOP tokens MUST be short-lived, per-request credentials. The server defines the maximum acceptable age of the iat claim; when cnonce is required, epop_cnonce_step_seconds imposes an additional validity bound enforced independently by both the AS and RS. Short lifetimes limit the window during which a captured token remains usable and reduce the cost of maintaining the jti replay cache.

Replay Prevention Each EPOP token MUST include a jti value of at least 128 bits of entropy (e.g., a UUID v4 or CSPRNG-generated value) to make collisions computationally infeasible. Servers MUST maintain a replay cache keyed on jti with a TTL of at least max_epop_lifetime + clock_skew; any token whose jti appears in the cache MUST be rejected. When cnonce is also required, the time-step window narrows the effective validity period further but does not replace the cache.

Token Substitution The key binding check — sha256(outer jwk) == cnf.jkt from the nested credential — is the primary defense against token substitution. An attacker who captures an access token and wraps it in an EPOP envelope signed with their own key will produce a thumbprint that does not match the cnf.jkt embedded by the AS; the RS MUST reject the mismatch. For opaque access tokens, the RS MUST NOT cache introspection results beyond the EPOP token's validity window. When a client performs key rotation (), the AS MUST atomically update its server-side key binding before issuing new tokens; a stale cached result could cause the RS to validate a post-rotation request against the pre-rotation key.

Cross-Protocol Replay Without rctx validation, an EPOP token captured from one protocol or endpoint could be replayed at another within the token's validity window. Servers MUST validate rctx.res and rctx.method when those claims are present. Clients SHOULD always include rctx to maximize replay resistance.

Credential Confidentiality The ntk claim embeds the full OAuth 2.0 credential inside the EPOP envelope. Unlike bearer token flows where only the token value is sensitive, the entire compact serialization carries sensitive material. TLS is REQUIRED for all EPOP token transmissions; JWE MAY be applied for additional confidentiality over transports that cannot guarantee channel security. Refresh tokens embedded in ntk are particularly sensitive. Servers and intermediaries MUST NOT log EPOP token values in plaintext; the jti claim SHOULD be used as the audit correlation identifier instead.

Key Rotation Security The AS MUST validate both the outer and inner EPOP envelopes completely before issuing new tokens or updating key bindings. Partial validation would allow an attacker who holds a captured refresh token to inject a new key by constructing a valid outer envelope while providing an invalid inner envelope.

PKCE Requirement PKCE () is REQUIRED in all EPOP authorization code flows. Without PKCE, an attacker who intercepts the authorization code can generate their own key pair and wrap the code in a valid EPOP token signed with that key, bypassing key binding entirely. PKCE and EPOP protect complementary surfaces: PKCE binds the authorization request to the token request; EPOP binds the code to the client's key pair.

Authorization Request Key Binding Binding a public key thumbprint inside the authorization request URL (as defined for DPoP in Section 10) is not supported by this specification. Authorization requests travel through the browser redirect — an untrusted channel where a parameter can be silently replaced before the AS sees it. EPOP establishes key binding exclusively at endpoints where the client communicates directly with the AS over TLS: the token endpoint and, optionally, the PAR endpoint ().

Algorithm Selection EPOP tokens are generated per-request at high frequency; algorithm choice directly affects signing latency, token size, and security posture. The jwk embedded in every EPOP header makes key footprint particularly significant for constrained transports. Edwards curve algorithms are RECOMMENDED. Ed25519 is the primary choice — smallest public key, fastest deterministic signing, and 128-bit security adequate for short-lived credentials. Ed448 is appropriate for high-assurance environments requiring a larger security margin. ES256 is acceptable where Edwards curves are unavailable. RSA algorithms SHOULD NOT be used in new implementations. Implementations MUST follow .

Intermediary Transparency Because the EPOP proof is embedded within the token rather than transmitted as a separate header, EPOP tokens are transparent to intermediaries that forward the Authorization header without modification. Unlike DPoP, where loss of the DPoP header at any hop silently breaks proof-of-possession, EPOP's enveloped structure ensures that the proof travels with the credential through every layer of a distributed system. Resource servers MUST NOT accept EPOP tokens from which the outer envelope signature has been stripped or replaced by an intermediary; the full compact-serialized EPOP token MUST be forwarded unchanged.

Private Key Protection The security of EPOP depends entirely on the client's private key remaining secret. Private key material MUST never be logged, serialized into application state, or transmitted over any channel. Implementations MUST verify that no private key fields (d, p, q, dp, dq, qi) are present in the jwk header parameter before accepting or forwarding an EPOP token. On native and mobile platforms, clients MUST use platform secure storage (e.g., Android Keystore, iOS Secure Enclave), with private key operations performed inside the secure element where available so that key material never enters application memory. In browser environments, private keys MUST be generated as non-extractable CryptoKey objects via the Web Crypto API (extractable: false). Clients MUST NOT store private keys in localStorage, sessionStorage, IndexedDB, or any JavaScript-readable store; this prevents exfiltration by XSS or injected scripts running in the same origin. EPOP tokens MUST use asymmetric signature algorithms. Symmetric algorithms such as HS256 require the verifier to hold the same secret as the signer, making independent third-party verification impossible and introducing shared-secret distribution risk.

Privacy Considerations

Credential Visibility in Logs Because the ntk claim embeds the full OAuth 2.0 credential, an EPOP token is more privacy-sensitive than a typical bearer token: its compact serialization reveals the credential type, issuer, audience, and scope to any party that receives or stores it. Servers SHOULD apply data-minimization practices to audit logs — retaining only the jti and iat claims rather than the full token value. See for the normative logging and TLS requirements.

Key Identifier as Tracking Vector The cnf.jkt claim is a stable, long-lived public key thumbprint. If the same key pair is used across multiple authorization server or resource server deployments, the thumbprint functions as a cross-context tracking identifier. Clients SHOULD use distinct key pairs per authorization server to limit cross-context correlation. Key rotation () provides a mechanism for periodic key refresh independent of active sessions.

Resource URI Disclosure The rctx.res field encodes the target resource URI or URN and is part of the signed EPOP envelope, visible to any party that receives or logs the token. Clients MUST use TLS for all EPOP token transmissions to limit exposure to on-path observers. Resource identifiers that encode sensitive information (e.g., user identifiers embedded in path parameters) SHOULD be avoided in rctx.res.

Minimal Disclosure This profile does not require the EPOP envelope to carry user identity claims. User identity information belongs in the nested access token (ntk), not in the outer EPOP envelope. Implementations MUST NOT add user identity claims to the EPOP token header or payload unless required by a specific profile extension.

IANA Considerations

HTTP Authentication Scheme Registration This specification requests registration of the following entry in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" ():

Authentication Scheme Name:

EPOP

Pointer to specification text:

and of this document.

OAuth Grant Type Registration This specification requests registration of the following entries in the "OAuth Parameters" registry (grant type sub-table) established by Section 11.3:

Grant Type Name:

urn:ietf:params:oauth:grant-type:epop_code_grant

Change Controller:

IETF

Specification Document(s):

of this document

Grant Type Name:

urn:ietf:params:oauth:grant-type:epop_refresh_token

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Parameters Registration This specification requests registration of the following entry in the "OAuth Parameters" registry established by Section 11.2:

Parameter Name:

epop

Parameter Usage Location:

token request, pushed authorization request

Change Controller:

IETF

Specification Document(s):

, , , and of this document

OAuth Token Type Registration This specification requests registration of the following value in the "OAuth Access Token Types" registry established by Section 11.1:

Type Name:

EPOP

Additional Token Endpoint Response Parameters:

(none)

HTTP Authentication Scheme(s):

EPOP

Change Controller:

IETF

Specification Document(s):

and of this document

OAuth Token Type Identifiers This specification requests registration of the following entries in the "OAuth URI" subregistry of the "OAuth Parameters" registry established by Section 7.1:

URI:

urn:ietf:params:oauth:token-type:epop_access_token

Change Controller:

IETF

Specification Document(s):

of this document

URI:

urn:ietf:params:oauth:token-type:epop_refresh_token

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Token Type Hint Registration This specification requests registration of the following value in the "OAuth Token Type Hints" registry established by Section 4.1:

Token Type Hint Name:

epop_token

Change Controller:

IETF

Specification Document(s):

, , and of this document

JWT Claims Registration This specification requests registration of the following JWT claims in the "JSON Web Token Claims" registry established by :

Claim Name: ntk

Claim Description: Nested Token — the OAuth 2.0 credential embedded inside the EPOP envelope.

Change Controller: IETF

Specification Document(s): of this document

Claim Name: rctx

Claim Description: Request Context — a JSON object identifying the target resource and protocol action.

Change Controller: IETF

Specification Document(s): of this document

Claim Name: cnonce

Claim Description: Client Nonce — offline-derived HMAC value for replay resistance without server-issued nonce state.

Change Controller: IETF

Specification Document(s): of this document

Media Type Registration This specification requests registration of the following media type in the "Media Types" registry (), following the convention established by for explicitly typed JWTs and the recommendation in Section 3.11:

Type name:

application

Subtype name:

epop+jwt

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary; see , Section 3.1

Security considerations:

See of this document

Interoperability considerations:

n/a

Published specification:

This document

Applications that use this media type:

OAuth 2.0 authorization servers, resource servers, and clients implementing EPOP

Fragment identifier considerations:

n/a

Additional information:

Deprecated alias names for this type: n/a

Magic number(s): n/a

File extension(s): n/a

Macintosh file type code(s): n/a

Person and email address to contact for further information:

Ashwin Ambekar, ambekar@gmail.com

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Ashwin Ambekar

Change controller:

IETF

Provisional registration:

no

As specified in , the value of the typ header parameter for EPOP tokens is epop+jwt, per the convention of omitting the application/ prefix described in Section 4.1.9.

OAuth Authorization Server Metadata This specification requests registration of the following names in the "OAuth Authorization Server Metadata" registry ():

epop_supported

Metadata Description: Indicates the authorization server's EPOP support posture: "disabled", "recommended", or "required".

epop_ntk_types_supported

Metadata Description: JSON array of nested credential (ntk) formats accepted by the server: "jwt" and/or "opaque".

epop_key_rotation_supported

Metadata Description: Boolean indicating whether the authorization server supports EPOP atomic key rotation ().

epop_cnonce_seed

Metadata Description: Base64url-encoded 32-byte deployment seed used to scope offline client nonce (cnonce) derivation.

epop_cnonce_step_seconds

Metadata Description: Integer time-step duration, in seconds, used in client nonce (cnonce) computation and verification.

epop_cnonce_seed_id

Metadata Description: Opaque identifier for the current value of epop_cnonce_seed.

epop_cnonce_required

Metadata Description: Boolean indicating whether EPOP tokens presented to this server must include a cnonce claim.

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Protected Resource Metadata This specification requests registration of the following names in the "OAuth Protected Resource Metadata" registry ():

epop_supported

Metadata Description: Indicates the resource server's EPOP support posture: "disabled", "recommended", or "required".

epop_ntk_types_supported

Metadata Description: JSON array of nested credential (ntk) formats accepted by the server: "jwt" and/or "opaque".

epop_cnonce_seed

Metadata Description: Base64url-encoded 32-byte deployment seed used to scope offline client nonce (cnonce) derivation.

epop_cnonce_step_seconds

Metadata Description: Integer time-step duration, in seconds, used in client nonce (cnonce) computation and verification.

epop_cnonce_seed_id

Metadata Description: Opaque identifier for the current value of epop_cnonce_seed.

epop_cnonce_required

Metadata Description: Boolean indicating whether EPOP tokens presented to this server must include a cnonce claim.

Change Controller:

IETF

Specification Document(s):

of this document

EPOP Request Context Members Registry This specification requests creation of a new registry, "EPOP Request Context Members", under the "OAuth Parameters" registry group. The registry is to be maintained as Specification Required per . Initial registrations:

Member Name	Type	Description	Specification
res	String	URI or URN of the target resource or endpoint	of this document
method	String	Protocol action string	of this document
id	String	Client-generated correlation ID	of this document

SASL Mechanism Registration This specification requests registration of the following entry in the "SASL Mechanisms" registry established by :

Mechanism Name:

OAUTHEPOP

Security Considerations:

See of this document.

Published Specification:

This document.

Intended Usage:

COMMON

Owner/Change Controller:

IETF

References Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims.

Acknowledgments The author thanks the OAuth Working Group for their foundational work on DPoP (), PKCE (), and the related specifications that this document extends. The author thanks Joe DeCock (Duende Software) for observations on token size implications across access token formats and algorithm combinations.