Support for Indeterminate Decision / Evaluation Status in Authorization Responses

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

1. 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.

2. 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

3. 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.

4. 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.

No files, tests, or entry points are identified. First clarify whether the intended direction is a status field or an extended decision vocabulary, then establish the interoperability and backward-compatibility requirements; done means the specification change and its semantics are agreed.