AuthZEN: a standard request shape for authorization decisions

The control gap

Every authorization vendor has invented its own check API. The shape is always the same idea, a subject, an action, a resource, and some context, and the field names are always different. That difference is what makes an enforcement point expensive to move and what stops one PEP from consulting two PDPs. AuthZEN, produced by the OpenID Foundation, standardises the request and response so the interface stops being a lock-in surface.

What good looks like

Enforcement points speak one shape. Swapping or adding a decision point becomes a configuration change rather than a rewrite of every call site.

• Publish a discovery document so a client can find the evaluation endpoints without hard-coded URLs.
• Accept the standard subject, action, resource, and context shape, and map it onto your internal model rather than requiring callers to learn that model.
• Support batch evaluation, since a UI often needs many decisions at once and a request per decision does not scale.
• Return a decision plus a reason, so the caller can render something better than a bare denial.

A production workflow

1. The enforcement point builds an AuthZEN evaluation request from the call it is about to make.
2. It posts to the evaluation endpoint discovered from the configuration document.
3. The decision point resolves the subject, action, and resource against policy and answers.
4. The enforcement point proceeds or refuses, and the decision is retained with the reason and policy version.

Copy this

Endram serves the AuthZEN discovery document and both evaluation endpoints. The subject's properties carry the agent and delegated user, so the delegation chain survives the standard shape.

GET /.well-known/authzen-configuration
{
  "policy_decision_point": "https://endram.com",
  "access_evaluation_endpoint": "https://endram.com/access/v1/evaluation",
  "access_evaluations_endpoint": "https://endram.com/access/v1/evaluations",
  "capabilities": []
}

POST /access/v1/evaluation
Authorization: Bearer <key with the authorize scope>
Content-Type: application/json

{
  "subject":  { "type": "agent", "id": "refund-bot",
                "properties": { "delegated_by": "alice@example.com", "version": "3.1" } },
  "action":   { "name": "issue_refund",
                "properties": { "risk_class": "financial",
                                "arguments": { "amount_cents": 40000 } } },
  "resource": { "type": "order", "id": "4192" },
  "context":  { "environment": "production" }
}

# The batch endpoint takes the same shape as a list, for screens that
# need many decisions before rendering.

The properties bag is what makes this workable for agents. The standard shape carries subject, action, and resource; the delegated user, the risk class, and the concrete arguments ride in properties where policy can still see them.

Evidence to require

• The evaluation request as received, including the arguments that were sent.
• The decision, the reason, and the policy version that produced it.
• Which key made the request and whether it carried the authorize scope.
• Batch evaluations, so a screen that asked for fifty decisions is one auditable event.

Buyer checklist

• How many places in your codebase build a vendor-specific authorization request today?
• Could you point an enforcement point at a second decision point without changing code?
• Does the batch path exist, and is it used by the screens that need it?
• Is the delegated user visible in the request, or flattened into the subject?