AuthZEN responses currently require a boolean decision (allow / deny), with optional context for additional information.
In practice, there are cases where the PDP cannot complete evaluation, for example:
- attribute source unavailable
- external risk signal unavailable
- missing required context
Today, these are typically represented as:
{
"decision": false,
"context": {
"error": "risk_engine_unavailable"
}
}
This makes it difficult to distinguish between:
-
Deny → policy evaluated and access is not allowed
-
Evaluation failure → system could not determine the correct outcome
Both appear as deny at the decision level.
Why This Matters
- Enforcement Semantics
Policy Enforcement Points (PEPs) may need to react differently:
-
Deny → block request
-
Indeterminate → retry, fallback, step-up auth, or degrade access
Without a standard signal, each PEP must interpret context independently.
- Interoperability
The specification currently allows context to carry arbitrary information, but:
Its semantics are implementation-specific
- PEP behavior is not standardized
- Cross-vendor interoperability is limited
- Audit and Explainability
From a governance and audit perspective, it is important to distinguish:
-
“Access denied due to policy”
-
“Access denied due to system failure or missing data”
Collapsing both into deny reduces audit clarity and can lead to misleading conclusions.
- Alignment with Existing Models
Other authorization systems explicitly model evaluation uncertainty:
XACML: Permit / Deny / Indeterminate / NotApplicable
Many policy engines (e.g., OPA) distinguish between decision and evaluation failure
AuthZEN currently lacks an equivalent concept.
Current Workaround
Use of context:
{
"decision": false,
"context": {
"error": "PIP_UNAVAILABLE",
"retryable": true
}
}
This enables:
- retry logic
- fallback behavior
However:
- No standard meaning of fields like error or retryable
- No guarantee that PEP understands or honors them
- Still represented as deny at decision level
Proposal (Exploratory)
Introduce a distinction between:
Decision outcome
Evaluation status
Option A: Add status field
{
"decision": false,
"status": "indeterminate",
"context": {
"error": "PIP_UNAVAILABLE",
"retryable": true
}
}
Where:
- decision remains backward compatible
- status conveys evaluation reliability
Option B: Extend decision vocabulary
{
"decision": "indeterminate",
"context": {
"error": "PIP_UNAVAILABLE"
}
}
This is more expressive but may impact backward compatibility.
AuthZEN responses currently require a boolean decision (allow / deny), with optional context for additional information.
In practice, there are cases where the PDP cannot complete evaluation, for example:
Today, these are typically represented as:
This makes it difficult to distinguish between:
Deny → policy evaluated and access is not allowed
Evaluation failure → system could not determine the correct outcome
Both appear as deny at the decision level.
Why This Matters
Policy Enforcement Points (PEPs) may need to react differently:
Deny → block request
Indeterminate → retry, fallback, step-up auth, or degrade access
Without a standard signal, each PEP must interpret context independently.
The specification currently allows context to carry arbitrary information, but:
Its semantics are implementation-specific
From a governance and audit perspective, it is important to distinguish:
“Access denied due to policy”
“Access denied due to system failure or missing data”
Collapsing both into deny reduces audit clarity and can lead to misleading conclusions.
Other authorization systems explicitly model evaluation uncertainty:
XACML: Permit / Deny / Indeterminate / NotApplicable
Many policy engines (e.g., OPA) distinguish between decision and evaluation failure
AuthZEN currently lacks an equivalent concept.
Current Workaround
Use of context:
This enables:
However:
Proposal (Exploratory)
Introduce a distinction between:
Decision outcome
Evaluation status
Option A: Add status field
Where:
Option B: Extend decision vocabulary
This is more expressive but may impact backward compatibility.