AuthZEN and SARC
The OpenID Foundation standard for asking and answering access decisions.
Authentication has had standards for years: OAuth and OpenID Connect. Authorization had none. Each policy engine had its own API, and changing engines meant rewriting every point that asked. OpenID AuthZEN solves that part: it defines the format of the question a PEP asks a PDP and the format of the answer.
The question has four fields, the SARC model: subject (who asks), action (what they want to do), resource (on what) and context (data of the moment). The answer has one required field, decision, true or false.
In Xokepoint, the default mapping of a tool produces this question. It is in the PEP code and is the starting point of every tool call:
{
"subject": {"type": "identity", "id": "$token.sub"},
"action": {"name": "tools/call"},
"resource": {"type": "tool", "id": "$params.name"}
}$token.sub and $params.name are expressions evaluated over the verified token and the message: the subject and the tool name. The action is always tools/call. By default the resource is the tool itself. When the tool acts on something more specific, such as a repository, a mapping replaces the resource (COAZ-MCP mapping). After the projection, the PEP completes the context with the agent, the tool and the arguments (Trusted context).
When it denies, the PDP returns the reason in the response context, for example no_delegation or no_resource. The reason goes to the decision trace, not to the agent.
The question goes through the PIP
Before it reaches the PDP, the question goes through the PIP, which adds attributes from external sources (Enrichment). PEP, PIP and PDP run in the same process and exchange AuthZEN models, with no HTTP call between them. The format is the same as for a remote PDP, which keeps a change of decision engine possible.
A mapping can project more than one evaluation for the same call, and all of them must permit. A missing, malformed or failed answer never permits execution.