Deterministic Authorization Protocol

0. Abstract

TG-01 defines deterministic authorization between an automation caller (including an agent) and an execution surface. Intent is evaluated against bound policy state before any irreversible commit. Execution is authorized only by an explicit PERMIT decision. All other terminal outcomes prohibit execution.

Scope

• Canonical authorization request shape and required fields
• Deterministic evaluation contract over request R and policy state P
• Decision set: PERMIT | DENY | ESCALATE | SILENCE
• Receipt issuance, canonicalization, signing, and offline verification
• Failure, replay, and conformance requirements for TG-01-compatible implementations

Non-goals

• Regulatory or compliance mapping (out of band; see product/trust materials)
• Policy authoring languages or UI
• Executor implementation details after a verified PERMIT
• Transport security (TLS) beyond requiring integrity of request and receipt bytes

1. Terminology & conformance

The key words MUST, MUST NOT, SHOULD, and MAY are to be interpreted as in RFC 2119.

Request (R)

Canonical authorization request object submitted for evaluation.

Policy state (P)

The bound, versioned policy material used for a given evaluation (including its fingerprint).

Decision (D)

One of PERMIT, DENY, ESCALATE, SILENCE. No other protocol decision values exist.

Receipt

Signed artifact binding R (via fingerprint), D, surface/action binding, policy fingerprint, time, and key identity.

Executor

Component that may perform a side effect. MUST NOT execute unless it holds a verified PERMIT receipt for that request.

Authorization service

Component that evaluates authorize(R, P) → D and issues receipts.

2. Authorization request

A conforming caller MUST submit a canonical request object. Implementations MAY accept dialect aliases at ingress but MUST normalize to the canonical field set before evaluation and before any fingerprint is computed.

Example (illustrative)

{
  "surface": "system.filesystem",
  "action": "write",
  "target": { "path": "/etc/config" },
  "params": { "content_hash": "sha256:e3b0c442…" },
  "context": { "trace_id": "trc_9921" },
  "idempotency_key": "idem_7f2a…"
}

Wire encodings MAY nest fields (for example action as a dotted surface.action string). Normative identity is the post-normalization canonical object used for fingerprinting.

3. Evaluation semantics

Let authorize(R, P) → D be the evaluation function.

• For identical canonical request R and identical policy state P, a conforming implementation MUST produce identical decision D.
• External nondeterministic state MUST NOT influence D unless that state is explicitly bound into R or P.
• Evaluation MUST be fail-closed with respect to execution: only PERMIT authorizes downstream commit.

Malformed and incomplete input

The following conditions are not additional decision values. They are evaluation failures that MUST terminate as DENY (or, where policy explicitly withholds coverage, SILENCE - never as PERMIT):

UNKNOWN and TIMEOUT are not members of the decision set. They describe failure modes that map into DENY (or transport error before a decision is issued). A client that cannot obtain a terminal decision MUST treat the outcome as non-authorizing.

4. Decision model

The normative decision set is exactly:

PERMIT | DENY | ESCALATE | SILENCE

PERMIT

Authorization granted for the bound request. Executor MAY perform the side effect after verifying the corresponding receipt.

DENY

Explicit refusal. Executor MUST NOT perform the side effect.

ESCALATE

Policy-required intervention path. Executor MUST NOT treat ESCALATE as PERMIT. Escalation lifecycle is out of scope of the hot-path commit.

SILENCE

No authorization issued (withhold / no-match / fail-closed non-permit). Not an approval queue. Executor MUST NOT perform the side effect. MUST NOT be collapsed into DENY or PERMIT in protocol semantics.

Only PERMIT authorizes downstream execution. All other terminal states prohibit execution.

Expanded narrative semantics: Decision model.

5. Execution protocol

A conforming execution path is:

1. Request - caller constructs canonical R.
2. Evaluate - authorization service computes D = authorize(R, P).
3. Decide - emit terminal D from the decision set (§4).
4. Receipt - issue a signed receipt for the terminal decision (§6).
5. Verify - executor verifies the receipt offline (§7).
6. Commit - if and only if decision is PERMIT and verification succeeds, executor MAY perform the side effect.

Steps MUST NOT be reordered such that commit precedes a verified PERMIT receipt.

6. Receipt protocol

A conforming authorization service MUST issue a signed receipt for every terminal decision, including DENY, ESCALATE, and SILENCE. Receipts are evidence of evaluation, not solely of permission.

Required fields

Canonicalization and signed bytes

• The signed preimage MUST be produced by deterministic JSON canonicalization (sorted object keys by Unicode code point; no locale-aware sort).
• The signature field itself MUST be excluded from the signed preimage.
• Implementations MUST document which fields enter the preimage for their receipt family.
• Once signed, the signed payload is immutable. Validator judgments MUST live in separate artifacts and MUST NOT mutate the receipt.

Schema and verification detail: Receipts, Verification guide.

7. Verification

• Executors MUST verify the Ed25519 signature against the issuer's published public key identified by key_id before treating a receipt as authoritative.
• Verification MUST be possible offline using only: the receipt bytes, the issuer public key material, and this specification (plus the published receipt schema).
• Public keys SHOULD be discoverable from a published key document (for example /.well-known/trigguard-keys.json).
• If verification fails (bad signature, unknown key, payload mismatch, unsupported algorithm), the executor MUST NOT execute. Failed verification MUST NOT be treated as PERMIT.

8. Failure semantics

Transport or infrastructure errors that prevent issuance of a terminal decision are not silent permits. Absence of a verified PERMIT receipt MUST be treated as prohibition of execution.

9. Replay & idempotency

• Callers SHOULD supply idempotency_key. For the same key and equivalent canonical R, implementations SHOULD return the same decision and MAY return the same receipt.
• A receipt MUST NOT be reused to authorize a different request. Binding is via request_fingerprint (and related surface/action/target fields).
• Executors MUST bind commit to the verified receipt for this request. Replay of an old PERMIT receipt against a mutated target or params MUST fail verification or binding checks.
• Request identity for replay prevention is the pair (caller/tenant scope, idempotency_key) when present; otherwise the canonical request_fingerprint.

10. Security properties

Guarantees

• Determinism - identical canonical R and P → identical D (§3).
• Fail-closed execution - only verified PERMIT authorizes commit.
• Immutability of signed receipts - signed payload is permanent evidence.
• Offline verifiability - no live service dependency required to verify a receipt.
• Non-repudiation of issuance - Ed25519 signature under published key material.

Non-guarantees

• Correctness of caller-supplied context that was bound into R
• Safety of the executor after a verified PERMIT
• Regulatory compliance by virtue of protocol conformance alone
• Availability of the authorization service

11. Threat model

Assumptions

• Signing keys are protected; public keys are authentically published.
• Executors enforce receipt verification before commit.
• Policy state P is integrity-protected and pinned for evaluation.

Trust boundaries

• Caller / agent is untrusted with respect to side effects.
• Authorization service is trusted for evaluation and signing.
• Executor is trusted to withhold commit without verified PERMIT.

Threats and mitigations

• TV-01 Privilege escalation via prompt injection - natural language is not an authorization input; only structured R and P decide.
• TV-02 State drift across multi-step runs - each irreversible step requires its own evaluation; receipts bind specific request fingerprints.
• TV-03 Non-auditable commits - commit requires a signed receipt; offline verification enables independent audit.
• TV-04 Receipt replay - fingerprint and binding checks (§9).
• TV-05 Fail-open on outage - prohibited (§8).

12. Conformance

An implementation MAY claim TG-01 compatibility only if it satisfies all of the following:

• Emits only the four normative decisions and never invents additional decision tokens
• Implements authorize(R, P) determinism as defined in §3
• Issues signed receipts for all terminal decisions (§6)
• Uses Ed25519 over canonical signed payload for OER receipt signing (§6-§7)
• Ensures executors verify before commit and refuse execution without verified PERMIT
• Maps evaluation and infrastructure failures to non-authorizing outcomes (§8)

13. Versioning

• This document's revision is independent of product SDK versions.
• Breaking changes to decision semantics, signed preimage construction, or required receipt fields MUST bump a protocol version field and MUST NOT silently reinterpret old receipts.
• Receivers SHOULD reject unsupported protocol_version values fail-closed.
• Additive optional fields MAY be introduced without a major bump if ignored by older verifiers without changing signed preimage identity for existing fields.

14. References

• Protocol overviewHuman-readable TG-01 introduction
• Decision modelPERMIT / DENY / ESCALATE / SILENCE narrative
• ReceiptsReceipt schema and binding notes
• Verification guideOffline verification procedures
• Receipt explorerInteractive verification tool
• API referenceHTTP execution surfaces
• Compliance mappingNon-normative regulatory alignment (not part of TG-01)