# Authorization Flow

This section describes the operational flow required to authorize a containment or release action in Overra. The authorization process is deterministic and cryptographically enforced. Only a valid wallet signature from the registered authority can trigger a state transition.

***

### Overview

**The authorization flow follows a fixed sequence:**

1. Initiate request
2. Construct authorization payload
3. Sign payload with wallet
4. Submit signed request to local agent
5. Local verification
6. State transition and enforcement
7. Audit logging

Each step is required.

There are no shortcuts or fallback mechanisms.

***

### Step 1: Initiate Request

The user initiates a containment or release request through the dashboard interface. The dashboard does not execute enforcement directly. It prepares a structured authorization payload.

***

### Step 2: Construct Authorization Payload

**The dashboard generates a structured message containing:**

* Requested action (`containment` or `release`)
* Device identifier
* Unique nonce
* Timestamp
* Expiration window

**The payload binds the request to:**

* A specific device
* A specific moment in time
* A single execution instance

***

### Step 3: Wallet Signature

The registered wallet signs the payload using Ed25519. The signature provides cryptographic proof that the request originated from the authorized wallet. Private keys never leave the wallet. The dashboard does not store credentials.

***

### Step 4: Submit to Local Agent

The signed payload is transmitted to the local agent via local communication endpoint. The agent does not trust the dashboard. All verification occurs locally.

***

### Step 5: Verification

**The local agent performs sequential validation:**

* Signature authenticity
* Authority match
* Nonce uniqueness
* Timestamp validation
* Expiration window check

**If any step fails:**

* Request is rejected
* State remains unchanged
* Failure is logged

**If all checks pass:**

* Authorization is approved
* State transition proceeds

***

### Step 6: State Transition and Enforcement

**If approved:**

* The endpoint transitions state (NORMAL → CONTAINED or vice versa)
* The Containment Engine executes predefined enforcement actions
* Enforcement completion is confirmed

Containment is deterministic and predefined. No arbitrary commands execute.

***

### Step 7: Audit Logging

Every authorization attempt is recorded.

**Logs include:**

* Timestamp
* Action requested
* Verification result
* State transition outcome

Both successful and rejected requests are logged.

***

### Failure Scenarios

**Authorization may fail due to:**

* Invalid signature
* Unregistered authority
* Reused nonce
* Expired timestamp
* Malformed payload

**In all failure cases:**

* State remains unchanged
* No partial enforcement occurs
* Event is logged for auditability

***

### Flow Summary

**The authorization flow ensures that containment is:**

* Cryptographically authorized
* Replay-resistant
* Time-bound
* Deterministic
* Locally enforced
* Transparently logged

No centralized system can bypass this process. Containment authority is exclusively derived from valid wallet signatures.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://overra.gitbook.io/overra-docs/usage/authorization-flow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.