Pulse Authorization: Identity-Aware Policy Enforcement with AuthZEN

Continuous Authentication establishes that the right person is still present. Pulse Authorization determines what they — and the agents acting on their behalf — are permitted to do. Together they form a complete, continuously-evaluated trust and authorization model.

See It in Action Technical Reference

Authentication Proves Who. Authorization Determines What.

Most security frameworks treat authentication and authorization as separate concerns, stitched together at integration time. Pulse treats them as a single continuously-evaluated pipeline. The trust signals produced by Continuous Authentication flow directly into authorization policy evaluation — meaning every access decision is made against a live picture of identity trust, not a stale credential from login time.

Dual-Assertion Identity: The Foundation of Pulse Authorization

Before any authorization decision can be trusted, the identity behind it must be trusted. Pulse establishes that trust through two simultaneous, independent assertions rather than one.

Assertion 1: FIDO2 Device Assertion

The user's registered FIDO2 device — either a Passkey or AffirmedID Auth — provides a cryptographically verified assertion of device possession. This is the phishing-resistant authentication layer, aligned with NIST AAL2/AAL3 and the FIDO Alliance specifications. The device assertion proves the right authenticator is present and that the ceremony was not intercepted.

Assertion 2: Auth Identity Assertion

The AffirmedID Auth app running on the user's phone provides a continuous behavioral identity assertion — a live signal derived from behavioral biometrics, proximity, 3D location, and device health. Unlike the point-in-time FIDO2 assertion, the Auth identity assertion is active throughout the session, continuously affirming that the authenticated user is still the user in control.

Why Two Assertions Matter for Authorization

A FIDO2 assertion alone proves the ceremony was completed correctly. It does not prove the user is still present five minutes later. An Auth identity assertion alone provides behavioral continuity but not cryptographic authentication strength. Together, they provide what authorization systems have always needed but rarely received: a continuously-valid, multi-layered identity assertion that can be relied upon not just at login but throughout every access decision in the session.

Authorization decisions made against dual assertions are fundamentally more trustworthy than those made against a session cookie from a login that may have occurred hours ago.

The Policy Decision Point: Real-Time Trust-Aware Authorization

The Pulse cloud PDP is the engine that translates continuous identity signals into authorization decisions. It sits between the Auth app's metric stream and the PEP's enforcement actions, operating in real time throughout the session lifecycle.

Continuous Metric Ingestion

The PDP continuously receives four trust metric streams from the Auth app, each updated in real time and linked to the session via correlation ID:

Identity Trust Score — behavioral biometrics continuously confirming the right person remains in control
Proximity Trust Score — Bluetooth-based physical presence confirming the user's phone stays near the access device
3D Location Trust Score — latitude, longitude, and barometric altitude. Standard geofencing is 2D and cannot distinguish floors within a building. Pulse uses barometric altitude from the user's phone to resolve floor-level position, so a user authenticated on floor 12 who moves to floor 3 registers a location anomaly even though both floors share the same street address and building footprint.
Device Health Trust Score — integrity monitoring covering jailbreak detection, hijack indicators, and anomalous device state changes

Trust Score Computation

Incoming metrics are evaluated against configurable policy rules and weighted into composite trust scores. Policy thresholds determine when trust is sufficient to continue, when step-up authentication is required, and when session termination is warranted. Thresholds are configurable per deployment, per user group, or per resource sensitivity level.

AuthZEN Policy Evaluation

The PDP implements AuthZEN access evaluation semantics. When an authorization query arrives — from the PEP, from an OIDC client, or from an AI agent workflow — the PDP evaluates it against current trust context, active policy rules, and the session's dual-assertion identity baseline. The response is a structured AuthZEN decision: permit, deny, or permit with conditions.

Decision Logging and Correlation

Every PDP decision — trust score update, policy evaluation result, enforcement action trigger — is logged with the session correlation ID, timestamp, metric values at time of decision, and the policy rule applied. This produces a complete, auditable authorization record for every session, ready for Splunk HEC ingestion or compliance reporting.

The Policy Enforcement Point: AuthZEN Evaluators in OIDC and SAML

The Pulse PEP is where authorization decisions become enforcement actions. It is implemented within the AffirmedID Connect OIDC provider and the SAML provider, giving it direct control over session state, token issuance, and access grants. The PEP exposes AuthZEN evaluator endpoints that are added to OIDC and SAML client configurations, making authorization queries a first-class part of the identity protocol flow.

AuthZEN Evaluators in OIDC Client Configuration

When an OIDC Relying Party (RP) registers with AffirmedID Connect, its client configuration includes the AuthZEN evaluator endpoints in addition to the standard OIDC parameters. This allows the RP to:

Query authorization inline: Send an AuthZEN access evaluation request directly to the evaluator endpoint during request processing — receiving a trust-context-aware permit or deny before serving the resource
Receive push notifications: Register a callback endpoint in the client configuration to receive push notifications when PDP trust decisions change mid-session — for example, when a trust score drops below threshold or a session is terminated by the PDP. The RP does not need to poll; the PEP notifies it.
Consume trust context in tokens: Optionally receive current trust scores and Auth identity assertion status as claims in ID tokens or access tokens, enabling downstream systems to make trust-aware decisions without a separate AuthZEN query

The evaluator endpoint URL and callback registration are added to the standard OIDC client metadata, keeping the integration within the OIDC protocol model rather than requiring a separate out-of-band configuration.

AuthZEN Evaluators in SAML Configuration

For SAML-based integrations, AuthZEN evaluator endpoints are included in the IdP metadata and service provider configuration. SAML service providers can:

Invoke access evaluation: Query the AuthZEN evaluator endpoint using the current SAML session context to obtain a real-time authorization decision before granting access to a protected resource
Register callback endpoints: Provide a callback URL in the SP configuration that receives push notifications when the PDP issues enforcement decisions affecting the session — enabling the SP to act on trust changes without waiting for a re-authentication event
Extend SAML assertions: Receive trust score attributes in SAML assertions, enabling trust-aware access control at the SP without requiring a separate out-of-band query for each access decision

Push Notifications: From Poll to Push

Traditional authorization models require relying parties to poll for changes in user state — an approach that is both inefficient and slow to respond. Pulse inverts this model. When a PDP decision changes the trust state of a session, the PEP pushes a notification to all registered callback endpoints immediately.

Push notification payloads include the session correlation ID, the type of trust event (threshold breach, step-up required, session termination), current trust scores, and a timestamp. Receiving systems can act on this notification within milliseconds — revoking a token, pausing an agent workflow, requiring re-authentication, or logging the event — without waiting for the next request cycle.

For AI agent workflows where sessions may run for hours without user interaction, push notification is not a convenience; it is a requirement. An agent that is notified of session revocation within milliseconds stops before it causes damage. An agent that discovers revocation at its next polling interval may have already taken unauthorized actions.

AuthZEN: The Authorization Evaluation Protocol

Pulse implements the AuthZEN access evaluation API specification — a standardized protocol for authorization queries between policy enforcement points and policy decision points. AuthZEN defines a consistent request/response model for access evaluation that is independent of the underlying authentication mechanism, making it composable with OIDC, SAML, and custom protocol stacks.

Access Evaluation Request

An AuthZEN evaluation request includes a subject (the identity making the request, derived from the dual-assertion session), an action (what is being requested), a resource (what is being accessed), and optionally a context object carrying additional signals — including current trust scores from the Pulse PDP. The Pulse evaluator uses all of this context to produce its decision.

Trust-Enriched Decisions

Pulse extends the standard AuthZEN response with trust context: the composite trust score at time of evaluation, the contributing metric values, and the policy rule that produced the decision. This gives downstream systems the information they need to apply graduated access controls — not just permit/deny, but permit-with-reduced-scope or permit-pending-step-up.

Low-Latency Evaluation

AuthZEN evaluations are designed for millisecond response times. The Pulse PDP maintains current trust state in memory, meaning evaluations do not require metric recomputation at query time. The evaluator reads current state, applies policy, and returns a decision — typically within single-digit milliseconds for in-session queries.

Hierarchical Agent Authorization

For multi-agent workflows, Pulse supports authorization chains where each agent in a hierarchy carries a scoped AuthZEN context derived from the root human session. Sub-agent authorization requests are evaluated not just against the sub-agent's permissions but against the trust state of the root session — ensuring that degraded human trust propagates through the entire agent chain.

End-to-End Authorization Flow

1. Session Establishment

User authenticates via AffirmedID Connect. The FIDO2 device assertion and Auth identity assertion are both verified. A session is created with a unique correlation ID. The Auth app begins streaming trust metrics to the PDP. Initial trust scores are computed.

2. Continuous Trust Evaluation

Throughout the session, the PDP continuously receives and evaluates metric streams. Trust scores are updated in real time. If thresholds are crossed, the PDP generates an enforcement decision and the PEP pushes notifications to all registered callback endpoints.

3. Resource Access Request

When the user or an agent requests access to a protected resource, the RP or SP sends an AuthZEN evaluation request to the PEP evaluator endpoint. The evaluator queries current PDP state, applies policy, and returns a trust-enriched decision — all within milliseconds.

4. Enforcement and Notification

The RP or SP enforces the decision. If the trust state changes between requests, the PEP pushes a notification to registered callback endpoints without waiting for the next request. Sessions are terminated, stepped up, or continued based on policy — automatically, in real time.

Authorization Compliance Alignment

Zero Trust Architecture

Every access decision is re-evaluated against current trust context. No implicit trust from prior authentication. Least-privilege enforced per request.

NIST SP 800-207

Continuous diagnostics and trust evaluation aligned with NIST ZTA principles. PDP decision logging satisfies continuous monitoring requirements.

AuthZEN Standard

Implements the OpenID Foundation AuthZEN access evaluation specification — a vendor-neutral, interoperable authorization protocol.

CMMC

Authorization audit trails, continuous monitoring, and policy-based enforcement meet CMMC Level 2 and Level 3 access control and audit requirements.

Ready to Go Beyond Authentication?

See It in the Demo

The self-serve demo shows AuthZEN evaluation in action — watch trust scores drive real-time enforcement decisions.

Start Demo

Technical Integration

API references for the AuthZEN evaluator endpoints, callback registration, and trust-enriched decision payloads.

Technical Docs

Talk to Us

Discuss your authorization architecture and how Pulse AuthZEN evaluators fit your OIDC or SAML stack.