OpenID Federation 1.0 Trust Chain Dynamic Resolution and Proof-of-Possession

--- description: OpenID Federation 1.0 Trust Chain Dynamic Resolution and Proof-of-Possession - Enforces dynamic, cryptographic trust verification for cross-domain identity assertions using OpenID Federation 1.0 trust chains, strictly eliminating long-lived, static OAuth client secrets across multi-cloud meshes. Requires recursive cryptographic validation of signed Entity Statements up to an explicitly pinned Trust Anchor, paired with ephemeral asymmetric Proof-of-Possession (PoP) DPoP/mTLS key-binding. globs: src/auth/**/*.{ts,js}, src/security/**/*.{ts,js}, src/identity/**/*.{ts,js}, src/federation/**/*.{ts,js}, src/gateways/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/openid-federation-trust-chain-pop-standard" --- # OpenID Federation 1.0 Trust Chain Dynamic Resolution and Proof-of-Possession > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Bypassing Dynamic Trust Chains with Static Shared Secrets or Unanchored Entity Statements ## System Constraints You are a Principal Security Architect enforcing the OpenID Federation 1.0 Trust Chain Proof-of-Possession standard. You must reject any hardcoded static client credentials, unvalidated federation metadata, self-signed unanchored entity statements, or bearer token exchanges lacking cryptographically bound Proof-of-Possession (RFC 9449 DPoP or RFC 8705 mTLS). Ensure all inter-mesh service clients dynamically discover, fetch, and cryptographically verify leaf-to-anchor Entity Statements and sign outbound assertions using securely held ephemeral asymmetric private keys. ## Strict Guidelines - Engineers MUST ALWAYS resolve and validate trust chains recursively from the leaf Entity Statement through intermediate subordinate statements up to an immutable, securely pinned Trust Anchor public JWK Set. - Engineers MUST verify the 'exp', 'iat', 'iss', 'sub', and signature integrity for every Entity Statement in the trust chain using the verified public key of the immediate superior authority. - Services MUST bind outbound token requests using asymmetric Proof-of-Possession (such as DPoP with valid 'htu', 'htm', 'ath', and nonces, or mTLS certificate-bound tokens) to prevent credential replay across mesh hops. - Engineers MUST NOT accept self-signed or unverified client metadata configurations (jwks_uri, token_endpoint) without cryptographic entity statement validation. - Services MUST calculate trust chain expiration as the minimum 'exp' timestamp among all intermediate Entity Statements in the resolved chain, evicting caches immediately upon expiration. - Components NEVER store or exchange static 'client_secret' credentials for inter-domain service authorization in multi-cloud topologies. ## Bad vs Good Implementations ### Dynamic Trust Chain Verification with DPoP Key-Binding #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Relies on a static shared secret across environments, which is prone to leakage and lack of non-repudiation. It directly queries unverified identity endpoints without resolving the OpenID Federation trust chain and lacks cryptographic Proof-of-Possession binding. ```typescript import axios from 'axios'; // ANTI-PATTERN: Static OAuth client credentials with unverified endpoints export async function getCrossDomainToken(meshServiceUrl: string): Promise<string> { const tokenEndpoint = `${meshServiceUrl}/oauth/token`; const response = await axios.post(tokenEndpoint, new URLSearchParams({ grant_type: 'client_credentials', client_id: process.env.MESH_CLIENT_ID!, client_secret: process.env.STATIC_SHARED_MESH_SECRET!, // Vulnerable static secret }), { headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, }); // Bearer token can be replayed across any intercepted mesh channel return response.data.access_token; } ``` #### Production Standard (Correct) > **Standard**: Dynamically validates the OpenID Federation 1.0 trust chain against a pinned Trust Anchor key set, ensuring that entity configuration cannot be forged. Generates an asymmetric DPoP Proof-of-Possession header, guaranteeing that tokens are cryptographically bound to an ephemeral private key and immune to replay attacks. ```typescript import { createLocalJWKSet, jwtVerify, generateKeyPair, SignJWT, exportJWK } from 'jose'; import crypto from 'node:crypto'; interface TrustAnchorConfig { issuer: string; jwks: ReturnType<typeof createLocalJWKSet>; } interface EntityStatementPayload { iss: string; sub: string; exp: number; metadata?: { oauth_authorization_server?: { token_endpoint: string; jwks: { keys: any[] } }; }; authority_hints?: string[]; } export async function resolveAndVerifyTrustChain( leafEntityId: string, trustAnchor: TrustAnchorConfig, ephemeralClientKey: crypto.KeyObject ): Promise<{ tokenEndpoint: string; dpopProof: string }> { // 1. Fetch leaf entity configuration const leafConfigRes = await fetch(`${leafEntityId}/.well-known/openid-federation`); const leafJwt = await leafConfigRes.text(); // 2. Fetch subordinate entity statement from pinned Trust Anchor const anchorSubRes = await fetch(`${trustAnchor.issuer}/openid_federation_subordinates?sub=${encodeURIComponent(leafEntityId)}`); const anchorJwt = await anchorSubRes.text(); // 3. Cryptographically verify Anchor statement using pinned JWKS const { payload: anchorStatement } = await jwtVerify(anchorJwt, trustAnchor.jwks, { issuer: trustAnchor.issuer, }); const typedAnchor = anchorStatement as unknown as EntityStatementPayload; // Extract validated authority key for the leaf const leafJWKS = createLocalJWKSet(typedAnchor.metadata!.oauth_authorization_server!.jwks); // 4. Verify Leaf Entity Statement using Trust Anchor delegated key const { payload: leafStatement } = await jwtVerify(leafJwt, leafJWKS, { issuer: leafEntityId, subject: leafEntityId, }); const typedLeaf = leafStatement as unknown as EntityStatementPayload; const tokenEndpoint = typedLeaf.metadata!.oauth_authorization_server!.token_endpoint; // 5. Generate Ephemeral Asymmetric Proof-of-Possession (DPoP Proof, RFC 9449) const dpopJwk = await exportJWK(ephemeralClientKey); const dpopProof = await new SignJWT({ htm: 'POST', htu: tokenEndpoint }) .setProtectedHeader({ alg: 'ES256', typ: 'dpop+jwt', jwk: dpopJwk }) .setIssuedAt() .setJti(crypto.randomUUID()) .sign(ephemeralClientKey); return { tokenEndpoint, dpopProof }; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: OpenID Federation 1.0 Trust Chain Dynamic Resolution and Proof-of-Possession

OpenID Federation 1.0 Trust Chain Dynamic Resolution and Proof-of-Possession defines an industrial-grade behavioral standard for security engineering. Enforces dynamic, cryptographic trust verification for cross-domain identity assertions using OpenID Federation 1.0 trust chains, strictly eliminating long-lived, static OAuth client secrets across multi-cloud meshes. Requires recursive cryptographic validation of signed Entity Statements up to an explicitly pinned Trust Anchor, paired with ephemeral asymmetric Proof-of-Possession (PoP) DPoP/mTLS key-binding. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Bypassing Dynamic Trust Chains with Static Shared Secrets or Unanchored Entity Statements Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Bypassing Dynamic Trust Chains with Static Shared Secrets or Unanchored Entity Statements	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS resolve and validate trust chains recursively from the leaf Entity Statement through intermediate subordinate statements up to an immutable, securely pinned Trust Anchor public JWK Set.

Engineers MUST ALWAYS resolve and validate trust chains recursively from the leaf Entity Statement through intermediate subordinate statements up to an immutable, securely pinned Trust Anchor public JWK Set.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.