• Title: Authorization Flow & Verification Architecture
• Status: Draft
• Category: Standards Track
• Version: 1.0
• Date: March 2026
• Authors: Swoop Engineering Team
• Related Specifications:
  • UniKey RFC 2001: Trust Packet Format & Canonicalization
  • RFC-1300: Device Authority & Operating System Integration Model

The UniKey Authorization Flow defines a decentralized, pre-execution verification model for digital actions. Unlike traditional "post-authentication" systems that rely on shared session state or centralized tokens, this architecture separates Authority Verification from Action Execution. By utilizing the Trust Packet as a transport-agnostic container, this specification enables any participating system—from AI agents to global payment rails—to independently and deterministically validate the intent and authorization of a request before commitment. This document establishes the normative sequence for Trust Packet generation, propagation, and stateless verification across heterogeneous networks.

This specification defines the authorization flow and verification architecture used by UniKey to validate digital actions before execution.

The goal of the UniKey authorization flow is to ensure that digital actions carry verifiable proof of authority that can be validated by any participating system without requiring shared state, proprietary integrations, or centralized authorization services.

This document defines:

• the sequence of authorization steps
• participating system roles
• how Trust Packets are generated and propagated
• how verification occurs prior to execution

This specification intentionally does not define business policies, user interfaces, or settlement logic.

Most digital systems today execute actions after verifying credentials such as passwords, tokens, or API keys.

UniKey introduces pre-execution authorization, where systems verify device-bound cryptographic authority before the action is executed.

The architecture therefore separates:

• authority verification
• execution and settlement

Authority is verified first.

Execution follows only after verification succeeds.

The UniKey authorization architecture includes the following logical participants.

The user's device generates Trust Packets using the device authority model defined in RFC-006.

The device confirms authorization and signs the Trust Packet Hash (TPH).

The initiating system is the application or service requesting execution of an action.

Examples include:

• merchant applications
• AI agents
• service APIs
• enterprise platforms

The integration layer forwards requests between initiating systems and verifiers.

Typical implementations include:

• payment service providers (PSPs)
• API gateways
• authentication proxies
• service middleware

The integration layer does not grant authority. It transports Trust Packets.

The verifier evaluates Trust Packets according to the rules defined in RFC-001.

The verifier performs deterministic validation of:

• signatures
• action binding
• audience binding
• replay protection
• delegation chains

Verification is stateless and independently reproducible.

The execution system performs the requested action after verification.

Examples include:

• payment networks
• banking systems
• blockchain smart contracts
• enterprise services
• API endpoints

Execution systems rely on verification results but do not generate Trust Packets.

The following sequence illustrates the standard UniKey authorization flow.

A device or agent requests an action from an initiating system.

Example:

User device → merchant application

The initiating system constructs a request describing the action.

The initiating system forwards the request to an integration layer.

Example:

Merchant → PSP or API gateway

At this stage the action is not yet authorized.

The integration layer requests authorization from the user device.

Example:

PSP → user device

The authorization request includes the canonical representation of the action.

The device confirms the action according to device policy and produces a Trust Packet.

The device signs the Trust Packet Hash defined in RFC-001.

The Trust Packet contains:

• action binding
• audience binding
• freshness constraints
• device authority signature

The Trust Packet is returned to the integration layer and forwarded along the transaction path.

Example:

Device → PSP → verifier

The Trust Packet accompanies the action request.

The verifier performs deterministic validation of the Trust Packet.

The verifier must validate:

• signature authenticity
• action binding
• audience match
• temporal validity
• replay protection
• delegation chain validity

If verification fails, the action must be rejected.

If verification succeeds, the action may be executed by the execution system.

Examples include:

• payment authorization
• API execution
• smart contract invocation

The UniKey architecture produces a chain of authorization events.

Each participant verifies the previous step and forwards the authorization context.

Example chain:

Device → Initiating System → Integration Layer → Execution System

Each step can independently verify the Trust Packet.

This creates a verifiable chain of authority without requiring a global ledger.

Trust Packets may travel through multiple systems before reaching the execution layer.

Systems forwarding Trust Packets must not modify any fields covered by the Trust Packet Hash.

Forwarding systems may add transport metadata outside the packet structure.

Any modification to the Trust Packet invalidates the signatures.

Verifiers must perform the validation steps defined in RFC-001 before allowing execution.

Verifiers must enforce:

• audience binding
• action binding
• replay prevention
• delegation chain integrity

Verification must fail closed.

If validation is incomplete or ambiguous, the action must be rejected.

UniKey verification is designed to operate without shared session state.

Verifiers may maintain a replay detection store for nonce or packet identifiers but do not require centralized coordination.

Any conforming verifier can independently validate a Trust Packet.

The authorization flow does not depend on a specific transport protocol.

Trust Packets may be conveyed using:

• HTTPS
• SMTP
• message queues
• event streams
• QR or NFC handoff

Security decisions must be based only on the canonical Trust Packet and verified signatures.

Transport metadata must not be trusted for authorization decisions.

The authorization architecture provides the following properties.

Actions are authorized before execution occurs.

Authorization requires possession of the device signing key.

Authorization is cryptographically bound to a specific action.

Authorization is valid only for the intended verifier.

Authorization artifacts cannot be reused.

Delegated authority cannot expand scope.

UniKey does not eliminate all attack scenarios.

Residual risks include:

• device compromise
• user deception
• domain key compromise
• malicious delegated agents

The architecture shifts attacks from scalable remote credential abuse to attacks requiring device compromise or user participation.

An implementation is conformant with this specification if it:

• follows the authorization flow defined above
• generates Trust Packets as defined in RFC-001
• uses device authority defined in RFC-006
• verifies Trust Packets before executing actions

Non-conformant flows must not be treated as valid UniKey authorization.