]> Independent

ietf@nritz.com

OAuth DPoP RATS HPKE This document describes IDPoP, an extension to DPoP that uses a key derivation scheme to separate access control from identity. It mitigates credential exfiltration risks by requiring fresh hardware attestation to unseal identity keys via an interactive challenge.

Introduction Standard DPoP binds tokens to keys but recent events have increased risks to exfiltration attacks where autonomous systems (such as agentic AI) leak valid credentials via prompt injection. Likewise, when malware compromises a device filesystem, attackers steal credentials and impersonate users until explicit revocation. This proposal introduces a derivation scheme separating access control (encapsulate/decapsulate) from identity (signing).

Key Material seed: High-entropy secret, encapsulated by the client's KEM Encapsulation Key (keK) and delivered to the client as sealed_seed. All HPKE seal/unseal and HKDF operations below are bound to a binding string carrying authorization intent (client_id + scope + audience), passed as the HPKE/HKDF info parameter. Two-Stage Derivation:

1. Access gating: keK is a KEM key pair generated natively inside the client's Target Environment, gated on producing valid Evidence (see Algorithm 1).
2. Identity derivation: K_attest = HKDF(salt=binding, ikm=seed, info="dpop")

| AS-B (OAuth) | | Client | 4. Present | Token Issuer | | (Attester) | AR grant '---+------+--------' | |<-| | ^ '------+------. +---------------+ | | 5. Validate AR | 6. Present token Issue access token | + DPoP proof | | (signed with K_dpop_priv) | v | .------+-------. 7. Validate token cnf | RS-B +------------> DPoP signature | (Resource | with K_dpop_pub | Server) | '--------------' ]]> Figure 1: OAuth Identity Chaining Flow with RATS Verifier as AS-A and "IDPoP"-aware OAuth AS-B as delegated notary NOTE: keK controls access to seed (identity key seed material). K_attest is the identity. Compromise of the identity key alone is insufficient—attacker needs to demonstrate access to notarized Evidence to derive keK and unseal.

Algorithms

Algorithm 1: DeriveKEM (Client) keK_priv never leaves the Target Environment and is not derived by feeding Evidence into an external HKDF call; this keeps the scheme compatible with TPMs and Secure Enclaves, which do not expose internal seeds for software-side key derivation.

Algorithm 2: EncapsulateSecret (AS-A)

Algorithm 3: DeriveIdentity (Client) Convergence: Client derives K_dpop_priv from (binding, seed) only after unsealing the encapsulated seed.

OAuth Identity Chaining Flow Setup (Client → AS-A):

1. Client generates attestation Evidence
2. Client: (keK_priv, keK_pub) = DeriveKEM(Evidence)
3. Client sends attestation to AS-A with keK_pub

Notarization (RATS Verifier as AS-A):

1. AS-A Appraises attestation Evidence
2. AS-A: (sealed_seed, K_dpop_pub) = EncapsulateSeed(binding, keK_pub)
3. AS-A creates JWT grant to AS-B:

Token Issuance (AS-B):

1. AS-B validates grant, issues DPoP-bound access token:

The access token JWT contains: Here, jkt validates the DPoP signature (standard DPoP), and idpop_managed_keysets enables the IDPoP liveness challenge.

Interactive Challenge & Proofs Interactive Challenge (AS-B → Client):

1. Client sends request with DPoP proof (no nonce or cached nonce)
2. AS-B decides: "I need hardware liveness proof"
3. AS-B → 401 Unauthorized

]]> Client Proof:

1. seed = HPKE.Unseal(keK_priv, sealed_seed) (proves fresh Evidence)
2. Client extracts sealed nonce from header
3. Client: nonce = HPKE.AuthUnseal(nonce_sealed, keK_priv, AS_B_pubkey)
4. Client: K_dpop_priv = HKDF(binding, seed, "dpop")
5. Client creates new DPoP proof with unsealed nonce and retries:

The DPoP proof JWT uses a proposed new type, idpop+jwt, and carries the public Identity Key (K_dpop) in its header: The corresponding payload: Verification (AS-B or RS-B):

1. Verify DPoP signature with K_dpop_pub (from token's cnf.jkt)
2. Verify proof.nonce == SHA256(expected_nonce)
3. Accept request

Note: The interactive challenge (Steps 8-10) introduces a round-trip. To mitigate latency, this challenge MAY be performed once per session or upon detecting high-risk context. The resulting nonce acts as a session binding signal for subsequent DPoP proofs, reducing overhead for high-frequency API calls.

Security Properties

1. No durable secrets at AS-A. Post-issuance compromise of AS-A yields no client key material. RATS Verifier (AS-A) computes K_dpop_priv transiently, extracts K_dpop_pub, discards both K_dpop_priv and secret seed material (seed).
2. Sealed grant confidentiality. Interception without keK_priv yields nothing. sealed_seed is HPKE-encrypted to keK_pub.
3. Attestation-bound unsealing. Stolen sealed_seed without device access is unusable. keK_priv is generated and retained solely inside the Target Environment, gated on producing valid Evidence. Unsealing seed requires fresh hardware attestation.
4. Key separation. keK controls access. K_dpop asserts identity. Compromise of signing key doesn't grant unsealing; compromise of unsealing requires live Evidence.
5. Convergent derivation. No key transport. Client derives K_dpop from (binding, seed) independently.

Security Considerations

Authorization Server as Root of Trust The architecture described in this document leverages the Authorization Server (AS-A in the RATS flow, or the OAuth AS) as a Trusted Third Party (TTP). This aligns with the standard OAuth 2.0 threat model , where the AS is already trusted to generate access tokens, sign ID tokens, and manage client credentials. While IDPoP introduces the generation and sealing of the Identity Key seed by the AS, this does not introduce a new root of trust. An AS capable of issuing a valid access_token can already impersonate the user to the Resource Server. Therefore, entrusting the AS with the transient generation of the seed is consistent with its existing role. The security goal of IDPoP is not to protect the client from the AS, but to protect the client's credentials from exfiltration after issuance.

Encapsulated Secret Transport This specification utilizes a Key Transport pattern where the Identity Key material (seed) is generated by the server and transmitted to the client in an HPKE-sealed envelope (sealed_seed). While Key Transport is sometimes disfavored in comparison to Key Agreement, it is necessary here to bind the identity to the specific hardware attestation presented by the client. Unlike a KEM shared secret consumed once for a transient liveness proof, seed is re-unsealed on each interactive challenge to re-derive the persistent signing key K_dpop, which remains valid for the life of the access token. The security of this transport relies on hardware binding: the seed is sealed to keK_pub, which is generated and retained inside the client's hardware-bound Target Environment. Even if sealed_seed is intercepted, it remains inert without the corresponding hardware-bound private key keK_priv.

"Harvest Now, Decrypt Later" and Forward Secrecy Encrypted transport of secrets is subject to "Harvest Now, Decrypt Later" (HNDL): an adversary records encrypted traffic today to decrypt it once quantum computing breaks current asymmetric primitives (e.g., X25519). The impact of HNDL on IDPoP is limited by the short lifetime of the identity key it protects. seed is used solely to derive the DPoP signing key (K_dpop), which is only useful for signing DPoP proofs during the validity period of the associated access token (defined by exp). If an adversary breaks the KEM years in the future and recovers a historical seed, the associated access token will have long since expired; unlike confidentiality keys protecting persistent data, recovering an authentication key after the session window has closed yields no advantage, provided the AS enforces standard expiration (exp) and replay protection (jti).

Post-Quantum Agility To further mitigate HNDL risks and ensure long-term resistance, implementations SHOULD support cryptographic agility in the HPKE configuration. Implementations can adopt hybrid KEMs such as X-Wing (combining X25519 and ML-KEM-768) for post-quantum resistance alongside classical security guarantees. The alg parameter in the attestation request or metadata allows the client and AS to negotiate Quantum-Resistant KEMs (e.g., ML-KEM) as they become standardized, keeping sealed_seed secure against future quantum cryptanalysis.

DPoP Proof Replay and Pre-Computation To prevent an attacker with temporary access to the signing key (or the ability to predict nonces) from pre-computing proofs, this specification mandates the use of HPKE-sealed nonces. Sealing the nonce to the client's keK_pub ensures that only a client with active access to the hardware-bound keK_priv can recover the nonce and sign the proof. This also limits the impact of a stolen cached K_dpop: malware holding it cannot pre-generate valid proofs for future requests, since it cannot decrypt future nonces without invoking the hardware anchor.

Normative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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 document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed.

Changelog

01

• restructured draft
• updated key and key input material names

Acknowledgments TODO