UniKey Core Specification
Abstract
This document defines the UniKey trust model.
UniKey is a universal method for proving identity, authority, and permission before actions occur on the internet. It is designed for humans, devices, software agents, and AI agents operating across open and untrusted environments.
UniKey does not rely on assumptions, stored sessions, shared secrets, or platform trust. Instead, it relies on cryptographically verifiable proof evaluated before execution.
This document defines what UniKey is, what must never change, and what it means to be UniKey-conformant.
1. Introduction
“Trust” is used constantly in technology. We say “trusted users,” “trusted devices,” “trusted networks,” and “zero trust.” Yet most systems do not clearly define what trust means.
In practice, trust is often treated as prior login, network location, session existence, platform ownership, or historical behavior. These are assumptions, not proof.
UniKey defines a model where trust MUST be demonstrated, trust MUST be provable using mathematics, trust MUST be evaluated at the moment of action, and trust MUST fail safely.
2. Scope
This specification defines the core invariants of UniKey.
An invariant is a rule that MUST always hold true regardless of implementation details, deployment environment, business model, cryptographic choices, or product design. If these invariants are violated, the system is not UniKey, even if similar terminology is used.
2.1 What This Specification Does Not Define
This document intentionally does not define user experiences, login flows, UI patterns, business logic, commercial models, or specific cryptographic algorithms. Those choices are left to implementations.
This separation is deliberate. It keeps UniKey universal, vendor-neutral, and future-proof.
2.2 Purpose of This Document
The purpose of this document is to define the unchanging foundation of UniKey. Implementations may evolve. Products may change. Cryptography may advance. These rules do not.
3. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.
3.1 Agent
An Agent is any entity capable of initiating an action. This includes humans, software processes, automated services, devices, and AI agents. UniKey treats all agents the same: what matters is not what the agent is, but whether it can prove it is allowed to act.
3.2 Device
A Device is an execution or approval environment. Devices matter because they can enforce local control, confirm presence, and bind actions to physical reality. Devices do not grant trust by themselves. Trust still requires proof.
3.3 Issuer
An Issuer creates signed statements of truth. Issuers may be domain owners, enterprises, email providers, or other trusted authorities. Issuers do not approve actions. They assert facts cryptographically.
3.4 Verifier
A Verifier evaluates proof and makes an allow/deny decision. A Verifier validates signatures, confirms issuer trust, evaluates authority, checks time bounds, and matches authority to the requested action. Verifiers do not guess.
4. UniKey Core Invariants (Normative)
All UniKey-conformant implementations MUST uphold every invariant in this section. These invariants are stable and define UniKey.
4.1 Trust Is Knowledge, Not Assumption
Definition. In UniKey, trust means verifiable knowledge that an actor is allowed to perform an action. Trust MUST NOT be based on prior login, network location, session existence, platform ownership, or historical behavior.
Rationale. Assumptions fail silently. When trust is assumed, systems allow actions before verification, detect abuse after damage, and cannot clearly explain authorization decisions. UniKey replaces assumption with proof.
4.2 Trust Must Be Cryptographically Provable
Definition. All trust claims in UniKey MUST be backed by cryptographic proof. Proof MUST be verifiable by independent parties, based on asymmetric cryptography, and resistant to forgery.
Rationale. Cryptography is mathematical, not contextual. Asymmetric cryptography allows anyone to verify a claim while only the holder of a private key can create it. This makes trust objective, deterministic, and machine-verifiable.
4.3 Identity, Authority, and Action Are Separate
Definition. UniKey treats identity, authority, and action as distinct concepts. Identity answers who is acting. Authority answers what is allowed. Action answers what is being requested now. No single proof MAY substitute for all three.
Rationale. Most systems combine these concepts, leading to over-permission, ambiguous failure modes, and increased blast radius. Separation limits damage and clarifies intent.
4.4 Verification Occurs Before Action
Definition. All trust verification MUST complete before an action is executed. Verification after execution MUST NOT be considered valid UniKey behavior.
Rationale. Reactive security detects problems after damage occurs. UniKey prevents damage instead of responding to it. This shifts security from reactive to preventative.
4.5 UniKey Is Stateless
Definition. UniKey MUST NOT rely on stored sessions or remembered trust. Each request MUST carry sufficient proof to be verified independently.
Rationale. State creates hidden trust. Hidden trust is difficult to audit, easy to steal, and hard to scale across systems. Stateless verification ensures every decision is explicit and accountable.
4.7 Trust May Travel with the Agent
Definition. UniKey allows trust to move with an agent across systems, provided proof remains valid. Trust MUST NOT be bound exclusively to a single application, a single platform, or a single account system.
Rationale. Agents operate across boundaries. Binding trust to platforms breaks interoperability, forces central control, and prevents open systems. Portable trust enables federated interaction.
4.8 Failure Must Be Safe and Explicit
Definition. When verification fails, the default behavior MUST be denial. UniKey MUST NOT guess, degrade to weaker security, or fall back to implicit trust.
Rationale. Security failures should be loud, not quiet. Explicit denial ensures predictable behavior and prevents accidental permission.
4.9 Summary of Invariants
UniKey is defined by these rules: trust is knowledge; proof replaces assumption; identity/authority/action are separate; verification precedes action; state is avoided; authority is limited; trust can travel; failure denies. Everything else is implementation detail.
5. Conformance (Normative)
This section defines what it means for a system to be UniKey-conformant. A system MAY use different transports, cryptographic algorithms, deployment models, or user experiences. However, a system MUST satisfy all invariants in Section 4 to claim UniKey compatibility.
5.1 Conformance Requirements
- Require cryptographically verifiable proof for every action
- Separate identity, authority, and action
- Verify all proof before execution
- Operate without stored trust state or sessions
- Enforce explicit, limited, and revocable authority
- Deny actions safely and explicitly on failure
Failure to meet any requirement breaks conformance.
5.2 What Conformance Does Not Require
- A specific UI or UX
- A specific login or onboarding flow
- A specific cryptographic algorithm
- A centralized service
- A specific vendor or platform
Conformance is architectural, not commercial.
5.3 Partial Adoption
Systems MAY adopt UniKey concepts incrementally. However, partial adoption MUST NOT be described as full UniKey conformance. Systems that reintroduce assumptions or implicit trust MUST NOT claim compatibility. UniKey conformance is binary, not gradual.
6. Threat Model Mapping
This section maps invariants to threats for evaluation and audit clarity.
6.1 Impersonation
Threat. An attacker pretends to be a legitimate user, service, or agent.
Mitigated by. §4.1, §4.2
6.2 Session Hijacking
Threat. An attacker steals or reuses a valid session or bearer token.
Mitigated by. §4.5, §4.4
6.3 Over-Permission
Threat. An actor is allowed to do more than intended.
Mitigated by. §4.3, §4.6
6.4 Replay Attacks
Threat. Previously valid proof is reused later to perform an action.
Mitigated by. §4.4, §4.6
6.5 Silent Failure or Degraded Security
Threat. A system fails open or falls back to weaker security.
Mitigated by. §4.8
6.6 Platform Lock-In and Trust Silos
Threat. Trust is trapped inside platforms or account systems.
Mitigated by. §4.7
7. Non-Goals and Anti-Patterns
Systems that rely on the patterns below MUST NOT claim UniKey conformance.
7.1 Anti-Pattern: Session-Based Trust
If trust is granted because a session exists, a user logged in earlier, or a token/cookie is present, the system is relying on remembered trust. UniKey requires proof per action.
7.3 Anti-Pattern: Verify-After-Execution Security
If security checks occur after an action completes (cleanup, monitoring, alerting), damage has already occurred. UniKey requires verification before action.
7.4 Anti-Pattern: Fallback to Weaker Security
If verification fails and the system falls back to passwords, reduced access, or assumed safety, it reintroduces assumption. UniKey failure behavior is deny.
7.5 Anti-Pattern: Platform-Bound Trust
If trust only works inside one ecosystem, one vendor, or proprietary APIs, it defeats portability and interoperability. UniKey is designed for the open internet.
8. Reference Conformance Checklist (Informational)
A UniKey-conformant system MUST be able to answer “yes” to all of the following:
- Does every action require cryptographically verifiable proof?
- Is identity verified independently of authority?
- Is authority explicit, scoped, and time-limited?
- Is verification completed before execution?
- Can every request be evaluated without stored trust state?
- Does failure always result in explicit denial?
8.1 Red Flags (Non-Conformance Indicators)
- Reliance on sessions or remembered trust
- Identity automatically implies authority
- Actions occur before verification completes
- Security relies on detection rather than prevention
- Trust only works inside a single platform
9. Versioning and Stability (Normative)
9.1 Invariant Stability
The core invariants in Section 4 are stable and MUST NOT change across versions. Any system that violates an invariant is no longer UniKey-compatible.
9.2 Implementation Evolution
Implementations MAY evolve in cryptographic algorithms, proof formats, transport mechanisms, and performance optimizations, provided all invariants remain satisfied.
9.3 Compatibility Behavior
Verifiers SHOULD be designed to ignore unknown fields, enforce known invariants, and reject unknown behavior conservatively. Backward compatibility MUST NOT weaken security.
10. Security Considerations
UniKey assumes attackers exist and systems will be probed. Security emerges from explicit definitions, mathematical proof, pre-execution enforcement, minimal authority, and safe failure.
UniKey’s purpose is not to make compromise impossible; it is to prevent silent, scalable abuse by requiring proof at the moment of action and denying safely when proof is missing or invalid.
11. Conclusion
Trust is one of the most abused words in computing. UniKey makes trust precise.
Trust is not assumed. Trust is proven. Proof comes before action. That is the UniKey invariant.