• Title: Device Authority & Operating System Integration Model
• Status: Draft
• Category: Standards Track
• Version: 1.0
• Date: March 2026
• Authors: Swoop Engineering Team
• Canonical URL: /rfc-1300

This specification defines the cryptographic and architectural requirements for establishing device-bound authority within the UniKey ecosystem. By leveraging hardware-backed security boundaries and operating system integrity, RFC-1300 ensures that authorization originates from a specific physical endpoint rather than reusable digital credentials. This model establishes the "Hardware Root of Trust" necessary for the secure generation of Trust Packets, enabling high-assurance actions in distributed, agentic environments while materially mitigating the risk of scalable remote fraud.

This specification defines how UniKey establishes device-bound cryptographic authority and how operating system security boundaries protect that authority.

The purpose of this document is to describe the security properties required for devices that generate Trust Packets and authorize digital actions.

Device authority ensures that authorization originates from a specific device security boundary rather than from reusable credentials such as passwords, tokens, or API keys.

This specification defines:

• the device authority model
• requirements for device key generation and protection
• operating system security assumptions
• authorization interaction requirements
• integration expectations for device platforms

This specification does not mandate a specific hardware platform, biometric mechanism, or operating system vendor.

The security objective of device authority is to ensure that the authorization of a digital action requires possession of a specific device and access to its protected signing key.

Under this model:

Credential compromise alone MUST NOT allow execution of actions.

Authorization requires the following:

1. possession of the device
2. access to the device's private signing key
3. explicit authorization by the device user or device policy

This model materially reduces the feasibility of scalable remote fraud.

In the UniKey architecture, the device acts as a cryptographic authority endpoint capable of issuing signatures over Trust Packets.

The device authority model consists of the following elements:

Device Private Key A cryptographic signing key stored within a protected device security boundary.

Device Identity An identifier associated with the device key.

Authorization Event A local event where the device confirms approval for a specific action.

Trust Packet Signature The device signs the canonical Trust Packet Hash (TPH) defined in RFC-001.

The resulting Trust Packet contains verifiable proof that the device approved the action.

Each participating device MUST generate or obtain a cryptographic signing key pair.

Device private keys MUST be protected by the device security boundary.

Recommended implementations include:

• secure enclave hardware
• trusted execution environments
• hardware-backed keystores

Private keys MUST NOT be exportable in plaintext form.

Public keys MUST be discoverable by verifiers using distributed key infrastructure mechanisms defined by UniKey.

Before signing a Trust Packet for a discrete action, the device MUST confirm authorization according to device policy.

Authorization confirmation MAY include:

• biometric authentication (e.g., Face ID, fingerprint)
• device passcode entry
• explicit user confirmation via system prompt
• trusted application policy

The authorization prompt SHOULD clearly display the action context derived from the Trust Packet payload.

Examples of context displayed:

• transaction amount
• merchant or relying party
• requested action
• destination or target

This ensures that user approval corresponds to the actual action being authorized.

When a device approves an action, it performs the following steps:

1. Receive the Trust Packet canonical representation (excluding signatures).
2. Verify the action context presented to the user.
3. Generate the Trust Packet Hash (TPH) as defined in RFC-001.
4. Sign the TPH using the device private key.
5. Return the signature as part of the Trust Packet signatures array.

The device signature binds the following fields:

• action payload
• audience
• context
• nonce
• expiration

This ensures that the authorization is specific, fresh, and non-replayable.

The UniKey device authority model assumes that the operating system enforces a security boundary protecting:

• private key storage
• biometric authentication mechanisms
• authorization prompts
• signing operations

The operating system MUST prevent untrusted applications from extracting private keys or silently triggering signatures.

Examples of platform protections include:

• application sandboxing
• secure key storage
• trusted user interface prompts
• secure enclave or hardware-backed key management

UniKey implementations rely on the integrity of this boundary.

Device compromise remains a possible attack scenario.

Examples include:

• malware with full system privileges
• compromised operating systems
• stolen unlocked devices

UniKey does not eliminate these attacks.

However, the architecture shifts fraud from scalable remote credential abuse to attacks requiring device compromise or user deception, which are significantly more difficult to automate at scale.

UniKey does not own, provision, or manage device-level cryptographic keys. Device binding is achieved by composing with the credential infrastructure of the carrier, payment network, or operating system layer that already manages device keys at scale under existing regulatory and security frameworks. The device is the approval trigger. The authority is domain-anchored and cloud-held.

UniKey recognizes three device binding models. Any one satisfies the device binding requirement.

Model A — Carrier Subscriber Provisioning (Ki path): The binding credential is the Ki or equivalent subscriber authentication credential provisioned by the carrier at SIM issuance. Enrollment is SIM activation. UniKey inherits the carrier's attestation guarantees.

Model B — Payment Network Token Binding: The binding credential is the payment token and device fingerprint managed by Visa, Mastercard, Apple Pay, or Google Pay. UniKey composes with the payment network's attestation infrastructure.

Model C — OS-Level Secure Hardware: Where UniKey is integrated at the OS or application layer, device binding is provided by Apple Secure Enclave, Android StrongBox, or TPM 2.0.

Regardless of binding model, the following properties must hold:

1. The device binding credential MUST be non-exportable from the device or SIM.
2. The approval signal MUST be authenticated to the UniKey cloud service before the Trust Packet is signed.
3. The binding MUST be traceable to a specific subscriber, token holder, or enrolled device. Unbound credentials MUST NOT be accepted as Trust Packet originators.

UniKey does not specify how these properties are implemented within each binding layer. That is the responsibility of the carrier, payment network, or OS vendor. UniKey specifies only that the properties must be satisfied.

Devices MAY delegate limited authority to trusted agents or applications.

Delegation MUST follow the Trust Packet delegation rules defined in RFC-001.

Delegated packets MUST:

• reference the parent Trust Packet hash
• narrow the permitted scope
• maintain the same audience and context constraints
• include an independent signature from the delegated authority

Delegation MUST NOT expand authority.

Verifiers must be able to obtain the public key associated with a device authority.

Public key discovery may occur through:

• domain-based key infrastructure (DNS/DKIM distribution)
• registry-based discovery
• platform key directories

The mechanism used MUST allow verifiers to validate the device signature independently.

The security of the Trust Packet does not rely on a centralized identity provider.

When implemented according to this specification and RFC-001, device authority provides the following properties:

Device Possession Requirement Authorization requires the signing device.

Credential Theft Resistance Stolen passwords, tokens, or account credentials alone cannot authorize actions.

Action Binding The device signature is bound to a specific action payload.

Audience Binding Authorization is valid only for the intended verifier.

Replay Resistance Authorization includes freshness constraints enforced by verifiers.

The UniKey device authority model is consistent with security assumptions used by modern device-bound authentication systems such as hardware security keys, FIDO passkeys, and device-based payment authorization systems.

These systems rely on the device security boundary to protect private signing keys.

UniKey extends this model to authorize arbitrary digital actions across distributed systems.

This specification defines required security properties but does not mandate specific hardware, operating systems, or biometric technologies.

Implementations may vary across device platforms provided they maintain the required security invariants.

A device implementation is conformant with this specification if it:

• generates or securely stores a private signing key
• performs user authorization confirmation before signing
• signs the Trust Packet Hash as defined in RFC-001
• protects the private key within the device security boundary
• prevents silent signing by untrusted software

Devices failing these requirements MUST NOT be treated as trusted authorities.