Post-Session Execution Assurance (PSEA)
A security model for verifying authority at the moment of action
What is Post-Session Execution Assurance (PSEA)?
Post-Session Execution Assurance (PSEA) is a security model. It requires cryptographic proof of user-verified presence, device trust, and execution authority at the exact moment a sensitive action is approved, independent of prior login or session state. Yuthent implements PSEA for regulated and mission-critical systems.
Introduction
Modern security architectures rely on a flawed assumption: that trust established at login can safely extend to all actions that follow.
Post-Session Execution Assurance (PSEA) defines a different model. One where authority must be proven at the moment a sensitive action is executed, not inherited from a past authentication event.
Formal Definition
Post-Session Execution Assurance (PSEA) is an architectural security model that requires cryptographic proof of user-verified presence, device trust, and execution authority at the exact moment a sensitive action is approved, independent of prior authentication or session state.
Specification Status
Status: Actively maintained IETF Internet-Draft, draft-yossif-psea-02, with intended status Standards Track. It is an individual submission: not yet adopted by an IETF working group, and it does not represent IETF consensus. The specification repository is public.
IETF Datatracker: datatracker.ietf.org/doc/draft-yossif-psea
Intended audience:
Security architects, regulators, standards bodies
Why Sessions Are Insufficient
Sessions answer who accessed a system at some point in time. They do not answer who is executing an action now.
In real-world systems, banking, healthcare, government, and critical infrastructure, risk materializes after login:
- ·when time has passed
- ·when context has changed
- ·when authority is delegated or replayed
- ·when devices or environments are no longer trustworthy
Authority is temporal, not persistent.
Core Principles of PSEA
Execution-Time Proof
Evidence is generated at the moment a sensitive action is approved, not in advance and not in arrears. Pre-generated or session-cached approval does not satisfy the model.
Human Presence Assurance
The proof carries evidence that a user-verified human was present at the device and approved this specific action. Presence is demonstrated, not assumed, and never inherited from a prior login. PSEA proves a human approved this action; it does not assert which human. Identity attribution is the deployment's responsibility.
Device-Bound Trust
Approval is bound to a specific physical authenticator. The signing key is hardware-protected, non-extractable, and invalidated by the platform on revocation. Transferable signing material does not satisfy the model.
Cryptographic Proof
Trust is proven cryptographically, not inferred from sessions, cookies, or bearer tokens. The evidence is independently verifiable and resistant to replay, forgery, and delegation.
Connectivity Independence
Evidence is produced at the moment of action and can be appraised later. The model permits deferred verification without admitting stale or unbound evidence; a deployment may require synchronous verification for its highest-assurance actions.
Wire Protocol & Proof Format
PSEA is specified as a wire protocol, not a product. The execution-time proof is an Entity Attestation Token (EAT) profile, defined in RFC 9711, carried as a compact JWS (RFC 7515) and signed with ES256 (ECDSA on P-256 with SHA-256).
The proof binds a SHA-256 hash of the exact action payload into the signed token, so what the verifier checks is what was approved: a What-You-Sign-Is-What-You-Execute binding. It carries the profile identifier urn:ietf:params:psea:eat-profile:1 and the media type application/psea+jwt.
The format is open end-to-end and self-contained: canonical JSON, compact JWS, a fixed signature algorithm, and a published claim set. Conformance is defined by the specification alone, with no vendor blessing, no shared secret, and no central registry of devices or issuers. PSEA complements OAuth 2.0 Step-Up Authentication (RFC 9470) by supplying the per-action, action-bound evidence a step-up flow can require.
What PSEA Is Not
PSEA is not:
- ·Multi-Factor Authentication
- ·Continuous Authentication
- ·Session Hardening
- ·Risk-Based Authentication
- ·Zero Trust rebranding
PSEA addresses a different problem: the absence of verifiable authority at execution time.
Relation to Yuthent
Yuthent is an implementation of the PSEA model, designed for regulated and mission-critical environments where sessions, OTPs, and fallback mechanisms cannot be trusted.
Implementing & Verifying PSEA
Everything required to build a conforming Attester or Verifier is in the specification itself. An independent party can implement directly from the draft, with no reference SDK, no shared secret, and no agreement with any vendor. The specification repository is the canonical home for implementers.
This page defines an architectural concept. Implementations may vary.