Authentication Entity Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
AUTHENTICATION ENTITY ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 04 November 2026 | Language: en-GB
Authors: Mark Anthony Higgins; Sky — Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/authentication-entity-ontology.html
Status: Original companion formalisation; page title and attribution verified, embedded specifications not accessible in retrieved page text.

1. PURPOSE
Represent authentication as a verifiable, time-bound process that establishes whether a claimant controls acceptable credentials for an asserted identity, without equating authentication with authorisation.

2. ENTITY MODEL
AuthenticationEntity A = (claimant, asserted_identity, factors, verifier, challenge, context, policy, evidence, result, expiry, provenance).
Related entities: IdentityEntity, CredentialEntity, AuthenticationFactor, SessionEntity, AccessControlEntity, SecurityControl, AuditRecord, ThreatEntity, HumanOperator.
Relations: CLAIMS_IDENTITY, PRESENTS_FACTOR, ISSUES_CHALLENGE, VERIFIES_EVIDENCE, SATISFIES_POLICY, ESTABLISHES_SESSION, RECORDS_RESULT, REVOKES_SESSION.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: identity claim, evidence, request context and current verification state.
R_t: authentication rules, factor requirements, trust and revocation rules.
B_t: boundaries for time, attempts, rate, origin, permissions and session lifetime.
K_t: known credentials, verifier trust, prior challenges, revocation and audit history.
Authentication lifecycle: UNVERIFIED -> CHALLENGED -> VERIFIED | REJECTED | EXPIRED | LOCKED.
A VERIFIED identity does not itself imply permission to perform an action.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | conforms(x, B_t) AND valid_evidence(x, K_t)}
x*_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, x*_t, evidence_t, result_t)
If V_t is empty: result_t = REJECTED; no authenticated session is issued.
If verifier status is unavailable or evidence cannot be validated: result_t = INDETERMINATE; fail closed for protected operations.

5. AUTHENTICATION PREDICATES
valid_factor(f) := authenticity(f) AND freshness(f) AND binding(f, claimant).
challenge_ok(c) := issued_by_verifier(c) AND unexpired(c) AND unused(c).
policy_ok(A) := required_factors_present(A) AND context_allowed(A) AND attempts_within_limit(A).
authenticated(A) := policy_ok(A) AND all_required_factors_valid(A) AND verifier_trusted(A).
session_valid(s) := authenticated_origin(s) AND unexpired(s) AND NOT revoked(s).
Authorised(action) requires a separate access-control decision.

6. INFERENCE RULES
R01: Identity claim without valid proof -> UNVERIFIED.
R02: Valid, fresh challenge response -> factor evidence accepted.
R03: Replayed or expired challenge -> REJECTED.
R04: Revoked credential -> REJECTED.
R05: Required factor missing -> CHALLENGED or REJECTED under policy.
R06: Repeated failures beyond policy limit -> LOCKED or throttled.
R07: Verifier trust failure -> INDETERMINATE; deny protected access.
R08: All required checks satisfied -> VERIFIED.
R09: VERIFIED plus session issuance policy -> bounded session created.
R10: Session expiry or revocation -> session invalidated.
R11: Suspicious context -> step-up verification or denial.
R12: Every final outcome -> privacy-minimised audit record.
R13: Authentication success does not imply authorisation.
R14: Material policy or credential change -> re-evaluate active trust where required.

7. MINI RECURSION ENGINE
Input: A_t, evidence_t, policy_t.
Repeat:
  collect permitted verification evidence;
  validate provenance, freshness and factor binding;
  apply policy and boundary filters;
  update authentication state and audit evidence;
  stop on VERIFIED, REJECTED, EXPIRED, LOCKED or configured attempt/time bound.
Termination guarantee applies only when finite retry/time bounds are enforced.

8. TRI-MAPPING
Human: A person or system proves control of accepted identity factors.
Semantic: Claimant -> credential/factor -> verifier -> decision -> bounded session.
Formal: authenticated(A) iff required evidence, verifier trust and policy predicates all hold.

9. MAPPING TABLE
Identity claim       | asserted_identity | CLAIMS_IDENTITY
Credential evidence  | factors           | PRESENTS_FACTOR
Verifier             | verifier          | VERIFIES_EVIDENCE
Challenge            | challenge         | ISSUES_CHALLENGE
Security policy      | policy, boundaries| SATISFIES_POLICY
Decision             | result            | RECORDS_RESULT
Session              | expiry, session   | ESTABLISHES_SESSION
Revocation           | revocation state  | REVOKES_SESSION

10. EXECUTION CONDITIONS
Preconditions: trusted verifier configuration, defined policy, protected credential handling, secure transport where relevant.
Invariant: never log secrets or reusable authenticators; preserve challenge freshness and factor separation.
Postconditions: explicit decision, audit provenance, and bounded session only after successful verification.
Guarantee: conditional procedural correctness under trusted inputs, correct implementations and enforced bounds; no absolute security guarantee.

11. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/authentication-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/authentication-entity-ontology.html
PURPOSE: Define identity authentication evidence, validation and state transitions.
STATE_MODEL: S=(I,R,B,K).
ENTITIES: claimant; identity; factor; credential; challenge; verifier; policy; session; audit record.
PATHWAYS: claim -> challenge -> verify -> policy check -> decision -> bounded session or denial.
MINI_RECURSION_ENGINE: bounded evidence-validation and policy-evaluation loop.
INFERENCE_RULES: R01-R14.
CONFIDENCE: only verified when all required evidence is valid; uncertainty fails closed.
SEMANTIC_EQUIVALENCE: authentication = identity proof verification; not access authorisation.
FLOW_HASH: compute SHA-256 over the final published file when deployed; not precomputed.
UPDATE_MODEL: versioned changes to credentials, factors, trust policy and revocation rules.

12. HOW TO READ
Interpret the equations as a formal reasoning framework, not executable code. Every predicate requires an implementation-specific verifier and testable acceptance criteria. Preserve the distinction between evidence validation, authentication decision, session validity and authorisation.

END OF FLOW