Authorization Objects (AO)

Abstract

RIP-100 defines Authorization Objects (AO): first-class, time-bounded, revocable authorizations that exist independently of execution. An Authorization Object represents explicit permission for a class of actions to occur, without prescribing when, how, or whether execution takes place.

This proposal defines no execution semantics.

Definition

An AO asserts:

“A grantor permits a grantee to perform an action within a defined scope, subject to explicit validity constraints.”

• Grantor — the entity granting authorization
• Grantee — the entity permitted to act
• Scope — an opaque description of the permitted action
• Validity window — explicit validAfter and validBefore bounds
• Nonce / salt — ensuring uniqueness
• Revocation semantics — a defined method for invalidation

The Authorization Object has a deterministic identity, typically derived as a cryptographic hash of its contents.

Non-goals

• How or when execution occurs
• Whether execution occurs at all
• Asset, value, or transfer semantics
• Scheduling, automation, or triggering behavior
• Enforcement mechanisms

Authorization Objects represent permission, not action.

Lifecycle

1. Creation — the grantor signs an Authorization Object
2. Existence — the object may be stored, transmitted, or observed
3. Evaluation — third parties verify validity at a given time
4. Revocation — the grantor invalidates the authorization
5. Expiration — the authorization ceases outside its validity window

At no point does the Authorization Object itself cause execution.

Profiles and infrastructure

Authorization Objects are intentionally generic. Domain-specific proposals may define profiles that interpret the scope field, and infrastructure that records or observes AO state.

• RIP-001 defines a financial authorization profile (“permissioned pull”).
• RIP-002 defines registry infrastructure for observing/verifying/revoking AOs.

Specification

Add your canonical RIP-100 draft link here when ready.

REPLACE_WITH_RIP_100_URL