OpenID AuthZEN / P*P

OpenID AuthZEN standardizes how an application asks a central policy service whether a user may perform an action, so that access rules can live in one governed place instead of being coded into every application. It defines the API boundary between Policy Enforcement Points (PEPs), the applications and API gateways that ask, and Policy Decision Points (PDPs), the engines that answer, as a common JSON interface. A PEP can therefore work with any compliant PDP, whatever policy language or engine it runs (XACML, OPA/Rego, Cedar, Zanzibar-style relationship engines, or plain access control lists), without custom integration for each one.

The Authorization API 1.0, a final OpenID specification since 11 January 2026, adopts the classic P*P architecture where PEPs ask "Can subject S perform action A on resource R under context C?" and PDPs evaluate policies to return permit/deny decisions with optional advice, obligations, and context. This separation promotes externalized, fine-grained, continuous authorization and aligns with Zero Trust principles by moving beyond the anti-pattern of embedding static entitlements in OAuth 2.0 access tokens.

Architecture and Information Model

AuthZEN defines a consistent JSON request/response model structured around the grammatical components of an authorization decision. Each evaluation request includes a subject (user, service principal, workload identity, or AI agent with attributes), an action (view, create, delete, etc.), a resource (with type, identifier, and attributes), and context (time, device posture, location, tenant). The PDP returns a decision with a boolean allow/deny flag, plus optional advice for field masking or redaction, and obligations such as logging requirements.

The final specification defines Access Evaluation for single decisions, Access Evaluations (batch/boxcar) for multiple evaluations in one call to reduce latency, and three Search APIs (subject, resource, and action search) that enable authorization-aware UIs by asking which subjects, resources, or actions are permitted rather than testing each candidate individually. The search capabilities support the pattern where a UI must filter a list to show only what a user can access, avoiding over-fetch and deny-at-display. They are worth one caveat when selecting a PDP: the search endpoints are normatively specified but optional to implement, so an interface designed around resource search depends on a capability a conformant PDP need not offer. The evaluation endpoints are the interoperable floor; search is a procurement requirement to state explicitly.

Interoperability and Policy Agnosticism

AuthZEN deliberately does not define a policy language, focusing instead on the API boundary between enforcement and decision points. This design allows organizations to adopt or change policy engines without rewriting application code, supporting Policy as Code frameworks including attribute-, role- and relationship-based access control (ABAC, RBAC, ReBAC), and hybrid models often described as Policy-Based Access Control (PBAC). The working group runs interoperability tests across independent PDP and PEP implementations.

The specification recommends transport over HTTPS with OAuth 2.0 for securing PDP endpoints, complementing rather than replacing existing authentication protocols like OpenID Connect. Where OAuth and OIDC handle delegated authorization and identity establishment, AuthZEN provides runtime, fine-grained access decisions based on current context, verified per request as Zero Trust requires.

Integration with Modern Security Frameworks

AuthZEN is designed to work alongside signal-sharing standards. The Shared Signals Framework (SSF) provides asynchronous security signal sharing through its Continuous Access Evaluation Profile (CAEP) and Risk Incident Sharing and Coordination (RISC) profiles, enabling AuthZEN evaluations to incorporate real-time session revocations, device compliance changes, and risk events. SSF delivers the signals, and the PDP behind AuthZEN takes them into account in the next decision.

Agent authorization is covered by two Working Group drafts. The Access Request and Approval Profile (ARAP) standardizes the request-and-approve interaction that human-in-the-loop authorization depends on, defining what a PEP does when a decision comes back denied but requestable rather than simply denied. COAZ (Compatible with OpenID AuthZEN) is a protocol-neutral framework for mapping an arbitrary protocol's information model onto an AuthZEN authorization request, and COAZ-MCP is its binding for Model Context Protocol, projecting MCP JSON-RPC calls and their parameters into subject, action, resource, and context. Mapping the parameters and not merely the tool name is what makes the resulting decision fine-grained: whether this agent, acting for this user, may call this tool with these arguments. COAZ is the more consequential of the two for existing deployments, because it externalizes MCP's per-tool access decisions to the same PDP an organization already runs rather than leaving them implemented inside each MCP server, which avoids a second, agent-specific policy silo.

Human-in-the-Loop Authorization

ARAP addresses a case the request/response model does not otherwise cover: an action the requester is technically permitted to take but which should not proceed without an explicit human decision. For high-risk or irreversible operations such as data deletion, financial transactions, or privileged infrastructure changes, a well-designed AI agent deployment pauses for approval regardless of the capability the agent holds, so the question shifts from whether the agent may act to whether a human has confirmed that it should.

From an authorization perspective this introduces a second principal into the decision. The approving human must be authenticated at the point of approval, and the approval recorded alongside the agent identity and the originally requesting user — three identities in one audit event rather than one. ARAP standardizes the request-and-approve interaction, but the approval still has to reach a person who is not in the agent's channel; CIBA is the finalized mechanism for that, delivering the prompt to a registered device without any credential passing through the agent. The approval should also be action-specific and time-bound; a standing "approve everything this agent does" grant reduces the pattern to an autonomous agent with extra ceremony. This is structurally the authorization-side counterpart to the OAuth 2.0 Step-Up Authentication Challenge, which suspends a request until the session reaches a higher assurance level; here the request is suspended until a distinct human confirms the specific proposed action. Expressing the risk thresholds that trigger a checkpoint in Policy as Code keeps them reviewable and consistent across agents rather than hardcoded into each implementation.

AuthZEN supports Zero Standing Privileges (ZSP) only in applications that ask the PDP on every request. There a privilege is a decision rather than a stored entitlement, and an approved elevation can be an attribute the policy checks for the length of a task. A target system that checks its own roles and group memberships keeps them whatever the PDP decides, so ZSP there still needs a mechanism that grants and revokes the entitlement in the target itself. Because every decision passes through the PDP, its decision log is also a central audit trail, which supports the governance objectives of frameworks such as the NIST Cybersecurity Framework.

Deployment Patterns and Adoption

Typical deployments follow a defense-in-depth pattern where API gateways perform coarse-grained route and method checks while applications enforce fine-grained authorization on domain objects, both calling the same PDP via AuthZEN. This enables centralized policy management with a decoupled lifecycle: policies can be edited, versioned, and audited without application redeployment. Organizations can implement caching strategies, circuit breakers, and local deny-by-default fallbacks to manage the latency and availability considerations inherent in external decision calls.

Reference implementations, interoperability test harnesses, and production deployments exist. What AuthZEN adds is a standard way to request and deliver authorization decisions, which is the piece that lets fine-grained, context-aware access control span many applications without one integration per policy engine.

Benefits and Considerations

AuthZEN's primary benefit is vendor interoperability—organizations can swap PDP implementations without changing PEP code, avoiding vendor lock-in while preserving the ability to evolve policy engines as requirements change. The framework enables continuous authorization through per-request decisions based on current context rather than static permissions, supporting least privilege and reducing the window of exposure from compromised credentials. Centralized decision logging enhances auditability for compliance, while batch evaluations and search APIs improve performance and user experience.

However, implementing AuthZEN requires careful attention to operational concerns. External PDP calls introduce latency, necessitating thoughtful caching strategies and fallback behaviors for network failures. Organizations must maintain attribute synchronization between systems, potentially using SSF/CAEP for real-time updates. The separation of policy from enforcement also requires governance processes to ensure policy accuracy and prevent authorization drift. For organizations running distributed, multi-cloud, or microservice architectures where authorization has to be consistent, the standardization usually outweighs this operational cost.