Skip to content
Research frameworkPolicy-driven · context-aware · multi-factor

Access should be earned by context, not just credentials.

TrustAccess is a policy-driven, context-aware multi-factor access verification framework that evaluates identity, device, location, time and contextual risk before making secure access decisions.

Explore the frameworkSee how it works
Reusable across protected environmentsIllustrative campus configurations
Fig. 01 / Context convergence
Illustrative
Request evidenceNormalized
User identitySession authVerified
DeviceRegisteredTrusted
GPS locationContainedInside zone
Dynamic QRFresh codeValid
Time contextIn windowOpen
Contextual riskAssessedLow
Evaluate
Verification enginePolicy + risk
PolicyRiskDecision
Decision / Allow

Illustrative outcome: policy passed and risk is low.

A diagram of the decision path, not a live request. All six signals are normalized into a verification context before policy and risk evaluation.
01

Policy remains authoritative

Contextual risk can raise scrutiny. It cannot override a hard-deny rule.

02

Evidence becomes context

Identity, device, location, QR and time are normalized before evaluation.

03

Trust is re-evaluated

An access decision starts a monitored session, not permanent trust.

02The security problem

Authentication proves identity. Context determines whether access should be trusted right now.

A valid credential answers one question. Secure access requires more: where the request comes from, which device is asking, whether physical presence is demonstrated, and whether the timing fits the policy.

A fair comparison. Most production authentication systems already combine multiple factors. The distinction is not “identity versus context.” It is whether a valid credential is treated as a permanent decision, or as one input to a governed, repeatable verification decision.

Static trust vs. contextual verification
Fig. 02 / Decision scopeConceptual comparison
Conventional model

Identity-only gate

Static decision
Credential or tokenInput
password · JWT · OAuth session
Credential status Valid
Access granteduntil expiry
Conditions left unchecked
  • Physical location
  • Device trust
  • Presence and timing
TrustAccess model

Context-aware verification

Repeatable decision
Identity
subject + role
Location
polygon containment
Device
registration state
QR / time
freshness + window
Authoritative
Policy engine
Contextual
Risk engine
Decision engine
ALLOWVERIFYDENY

A decision is created from the current context, then attached to a session that can be re-evaluated when the context changes.

Q1 / Identity

Is the requesting user authenticated?

Authentication establishes who is making the request. It does not describe the conditions of that request.

Q2 / Location

Is the request inside an authorized zone?

A valid session can be used from anywhere. Polygon containment checks whether the request originates in the protected area.

Q3 / Context

Are device, QR and timing consistent?

Device recognition, a fresh presence code and an allowed time window reveal whether the request matches the access policy.

03The TrustAccess approach

A small, auditable question asked every time.

Is this the right subject, under the right conditions, satisfying the right policy, at this moment? TrustAccess turns that question into a repeatable pipeline rather than a one-time gate.
01

Evidence, not assertion

Identity is one signal. Device state, location, QR freshness and timing describe the conditions of the request.

02

Policy before probability

Deterministic policy conditions are evaluated first. Risk can add scrutiny; it cannot erase a hard-deny rule.

03

Sessions, not sign-ins

Access creates a session with a context snapshot. The session remains subject to re-evaluation.

04

One framework, many policies

Attendance, events and laboratories change the policy configuration, not the verification architecture.

The framework is independent of any single application. A smart campus is where the policy model is configured and demonstrated.

Fig. 03 / Decision contractIllustrative control flow
01
Request
identity + context payload
02
Normalize
one VerificationContext
03
Policy
authoritative constraints
04
Risk
contextual suspiciousness
05
Decision
ALLOW · VERIFY · DENY

Successful decisions open sessions. Heartbeats compare new context with the session baseline.

Decision matrix
PolicyRiskResult
Hard deny / failNot authoritativeDENY
PassLowALLOW
PassElevatedVERIFY

Risk is an input to the decision, never a replacement for policy. Hard-deny conditions bypass probabilistic assessment.

Audit
Decision + context snapshotappend-only record
04Three core pillars

Trust, context and verification working as one.

Each pillar owns a distinct part of the decision. Together they turn fragmented signals and administrative rules into a coherent access decision — one that can be inspected and repeated.
Pillar 01

Trust

Identity & Authorization

Establishes who the user is, what they are permitted to do, and whether their device can be trusted. This pillar manages authentication, role-based access control, JWT-based sessions, and device registration.

Responsibilities07
  • Authentication
  • Identity Verification
  • JWT Token Management
  • Authorization
  • Role-Based Access Control
  • Device Trust
  • Secure Session Management
Pillar 02

Context

Environmental Evidence

Collects and normalizes contextual evidence from the requesting environment — including GPS coordinates, geofence boundaries, dynamic QR codes, device state, and temporal information — into a structured verification context.

Responsibilities08
  • GPS Collection
  • Geolocation Processing
  • Polygon Geofencing
  • Dynamic QR Validation
  • Time Context
  • Device State Assessment
  • Context Collection
  • Context Normalization
Pillar 03

Verification

Policy & Decision

Evaluates the normalized context against defined policies, assesses contextual risk, and produces a final access decision. This pillar also manages session lifecycle, periodic re-evaluation, and audit logging.

Responsibilities07
  • Verification Engine
  • Policy Engine
  • Risk Engine
  • Decision Engine
  • Session Lifecycle
  • Periodic Re-evaluation
  • Audit Logging

A shared framework, not three isolated modules

Every request is evaluated by the same trust, context and verification responsibilities. Only the policy configuration changes.

TrustContextVerificationDecision
05How verification works

Nine stages from request to auditable decision.

The pipeline is explicit and inspectable. Select any stage to see what it consumes, what it transforms and what it hands to the next component.
Fig. 04 / Verification pipeline
Lifecycle01 / 09

Stage inspector showing Identity Verification, stage 1 of 9

Stage 01Pipeline inspector

Identity Verification

Authenticate the requesting user and validate their credentials.

Inputs
  • User credentials
  • JWT token
  • Session identifier
Outputs
  • Authenticated user identity
  • User role
  • Authentication status
Processing

Validate identity through authentication service and verify active session.

Hand-off
Execution
Conceptual lifecycle, not a live run.
Ownership
Several stages may share one backend module.
Record
Decision + context snapshot → audit trail.

NoteThe pipeline is a conceptual lifecycle model. The guided trace is an educational walkthrough, not a live backend execution.

06Engineering blueprint

One verification spine, six clear layers.

The V1 backend is a modular monolith. Spatial data lives in PostgreSQL with PostGIS; contextual risk estimation is isolated in a separate FastAPI inference service.
Select architecture layer
2 components

User-facing applications that collect contextual evidence and present access decisions.

Modular monolith

Spring Boot hosts the verification services in one deployable application.

Spatial persistence

PostgreSQL + PostGIS evaluates polygon containment.

Separate inference

FastAPI estimates contextual suspicion; it does not own policy.

07Decision simulator

The result is never just a score.

Select an access request and step through identity, device, location, presence code, normalization, policy and contextual risk. The final decision is deterministic and explainable.
Fig. 06 / Verification runNo live backend · results are simulated
Request contextSCN-01
IdentityAwaiting evaluationqueued
RoleAwaiting evaluationqueued
DeviceAwaiting evaluationqueued
LocationAwaiting evaluationqueued
Dynamic QRAwaiting evaluationqueued
TimeAwaiting evaluationqueued

The context snapshot is written to the audit record with the final decision. Illustrative data only.

Verification traceReady
  1. 01IdentityAuthenticated identity and role
  2. 02DeviceSession device and familiarity
  3. 03LocationPostGIS polygon containment
  4. 04Dynamic QRSigned, fresh, unused code
  5. 05NormalizeAssemble one VerificationContext
  6. 06PolicyEvaluate deterministic constraints
  7. 07RiskEstimate contextual suspicion
  8. 08DecisionApply the decision contract

Awaiting evaluation

The final decision appears after policy and risk complete.

Time to decision is not a measured benchmark

No accuracy, latency or real-world deployment result is claimed here. The simulation demonstrates the decision contract described in the research model.

Illustrative only
08Session lifecycle

Access can outlive its context. The session should not.

A session is not a permanent grant. The framework binds continued validity to periodic contextual evidence and re-evaluation — and makes the consequence of every state transition explicit.
Fig. 07 / Session recordSimulated event sequence · no live session
ACTIVEVERIFY_REQUIREDREVOKEDEXPIRED
  1. T0

    Session admitted

    An ALLOW decision creates the access session and stores its context snapshot.

  2. T1

    Evidence received

    A periodic context snapshot is added to the session record.

  3. T2

    Re-evaluated

    Policy and contextual risk are evaluated again.

  4. T3

    Session maintained

    The new evidence supports continued access.

A heartbeat is periodic contextual evidence, not continuous biometric authentication. The evidence interval, retry policy and expiry window are deployment-specific; the framework does not claim uninterrupted monitoring.

Revocation is propagated to protected APIs.
Session evidence is retained for audit.

09Application demonstrations

One framework. Different context.

A classroom, a venue and a restricted laboratory need different evidence and different policies. The verification spine stays the same; the configuration changes.
Illustrative configurations · not deployment evidence
Fig. 08 / Domain configurationScheduled class
Presence + class membership + timing

Attendance verification

A student requests attendance for a scheduled class. The framework combines an authenticated identity, a fresh classroom QR, a classroom polygon and the class time window. If every constraint passes and contextual risk is low, attendance is recorded without interrupting the class.

Workflow configuration4 stages
  1. 01Request

    The student scans the classroom QR and submits an attendance request.

  2. 02Assemble

    Identity, role, QR, GPS, device and time are normalized into one context.

  3. 03Evaluate

    Policy checks the class window and classroom polygon; risk is estimated.

  4. 04Record

    An ALLOW decision writes attendance with its context snapshot.

Example context snapshotillustrative
IdentityStudent authenticated
RoleEnrolled in course
Dynamic QRFresh classroom code
LocationInside classroom polygon
TimeInside class window
Contextual riskLow
Example decision · ALLOWNot a live result

All explicit constraints pass and contextual risk is low.

Policy PASSRisk Low
Policy composition
  • Authenticated student with an active course enrolment
  • Signed QR within its freshness window
  • GPS inside the classroom polygon
  • Request inside the scheduled class window

These Smart Campus configurations demonstrate policy parameterization; they are not the core research contribution, a live deployment, or evidence of measured outcomes. The same verification framework can be configured for other domains.

Trace the shared pipeline
Fig. 09 / Spatial policy

A polygon is a policy, not proof of presence.

PostGIS evaluates the submitted point against a multi-vertex zone boundary. The result is one explicit input to policy — not a verdict on its own.

Request point · illustrative coordinateSRID 4326
FACILITY ENVELOPELAB-04 ZONE POLYGONmulti-vertex boundaryREQUEST POINTPoint-in-polygon is one signal. GPS can be spoofed.
ST_Covers = true
Spatial outcome

Constraint satisfied

The point is inside — or on the boundary of — the configured polygon. Other policy constraints and contextual risk still apply.

Why polygons

Rooms, labs and venue perimeters are rarely circular. A multi-vertex polygon can follow the actual authorized space instead of a generous radius that bleeds through walls.

Conceptual queryPostGIS · boundary-inclusive
-- ST_Covers includes the boundary;
-- use ST_Contains when the boundary is excluded.
SELECT ST_Covers(zone.geom, request.point)
FROM access_zones AS zone
WHERE zone.id = :zone_id;

Geofencing constrains a request; it does not prove physical presence. GPS is client-reported evidence and can be spoofed. Higher-assurance deployments should combine independent signals and define explicit boundary semantics.

10Research methodology

ML assists risk. Policy retains authority.

A deliberately small, interpretable model estimates contextual suspicion. It informs the decision layer; it does not decide access on its own, and it cannot soften a hard policy constraint.

Research integrity note

The figures below describe a planned synthetic evaluation harness. No accuracy, precision, recall, latency or deployment result is claimed. Measured metrics will be reported only after a controlled held-out evaluation is complete.

Fig. 10 / Dataset and feature designSynthetic · not field data
Dataset composition

10,000synthetic events

7,000 normal3,000 suspicious
Data origin
Synthetic only
Class balance
70 / 30
Evaluation model
Logistic Regression

The dataset is generated to exercise the verification pipeline. It is not a sample of real campus activity and does not establish external validity.

Contextual feature vector
6 features
F01

GPS Distance

Continuous · meters

Distance between the submitted coordinates and the authorized zone.

F02

Time Deviation

Continuous · minutes

Difference between the request time and the expected access window.

F03

Device Familiarity

Continuous · 0–1

How consistently this device has appeared in prior successful access.

F04

QR Validation Result

Binary · 0 or 1

Whether the presence code passed signature, freshness and replay checks.

F05

Recent Failures

Discrete · count

Failed access attempts by the same identity in a recent window.

F06

Access Frequency

Continuous · 0–1

Normalized historical frequency of this identity accessing the resource.

QR validation is included in the research feature vector. In the runtime decision contract, a hard QR failure is resolved by policy before inference, so the model is not asked to override it.

Research pipeline
Offline training · runtime inference
Training and evaluation

Build and assess the model before it informs runtime decisions.

Offline
  1. 01

    Synthetic generation

    10,000 labelled events: 7,000 normal, 3,000 suspicious.

  2. 02

    Validation

    Check ranges, missing values and label consistency.

  3. 03

    Preprocessing

    Scale continuous features and encode the binary QR result.

  4. 04

    Train / test split

    Hold out a stratified test set before any fitting.

  5. 05

    Train + baseline

    Fit Logistic Regression and the rule-based baseline.

  6. 06

    Held-out evaluation

    Compare accuracy, precision, recall, F1, FPR and FNR. Pending.

Runtime inference

Estimate risk only after deterministic policy has been evaluated.

Runtime
  1. 01

    Probability estimate

    Infer P(suspicious | context features) from the fitted model.

  2. 02

    Risk mapping

    Map the model output to a bounded risk score.

  3. 03

    Decision integration

    Policy remains authoritative; ML can only raise verification.

Evaluation protocol
Pending

The trained model will be compared with a deterministic rule-based baseline on a held-out synthetic split. The comparison is designed to test whether contextual risk estimation adds value over explicit rules.

AccuracyPrecisionRecallF1 scoreFalse positive rateFalse negative rate

Status: protocol defined, values not reported. No model-performance claim should be inferred from this page.

Output mapping

The model produces a probability, not a decision. The score is mapped into the policy contract; thresholds and tolerances are deployment configuration, not universal constants.

Trust Score = (1 − P(suspicious | x)) × 100
Model outputP(suspicious | x) ∈ [0, 1]
Not claimedProbability ≠ certainty. Calibration matters.
Policy authority

A model cannot override a hard deny.

If a deterministic constraint fails, the request is denied before inference. A high model confidence cannot rescue it; a low score cannot soften it.

if policy = HARD_DENY → DENY · ML skipped

if policy = PASS ∧ risk low → ALLOW

if policy = PASS ∧ risk elevated → VERIFY

Decision contract is explained in section 03
11Technical stack

The stack follows the boundaries.

Verification stays in one transactional backend. Spatial state lives in PostgreSQL with PostGIS. Contextual inference is isolated in a separate Python service. This is the intended V1 architecture, not a claim of a live deployment.
V1 targetPlannedEvaluation
Intended scope · no component is presented as production-verified
Fig. 11 / Component responsibilitiesModular monolith + isolated inference

Client

Evidence producer, not the decision authority.

Flutter

Mobile demonstration client

Submits authentication state, QR payloads and client-reported context to the verification backend. It does not decide access locally.

V1 target

Admin web console

Policy, zone and audit management

Separate administrative surface for policy and geofence configuration. It is not part of this public site.

Planned

Backend

One transactional verification path in a modular monolith.

Java 21 / Spring Boot

Verification backend

Hosts authentication, context normalization, policy, decision, session and audit modules within one deployable application.

V1 target

Spring Security

Authentication and endpoint authorization

Handles credential verification, stateless token handling and role-based endpoint protection.

V1 target

Spring Data JPA

Relational persistence and transactions

Manages entity persistence and transactional boundaries. Spatial predicates can be issued through native PostGIS queries.

V1 target

Spatial persistence

PostgreSQL is the system of record; PostGIS evaluates geometry.

PostgreSQL 16

Relational system of record

Stores identities, policies, zones, session state and audit events. Schema changes should be migration-managed.

V1 target

PostGIS

Polygon containment

Evaluates point-in-polygon predicates such as ST_Covers for boundary-inclusive zones. Boundary semantics must be explicit.

V1 target

Machine learning

Separate inference lifecycle, subordinate decision authority.

Python / FastAPI

Isolated inference service

Exposes a bounded inference endpoint to the backend. It is operationally separate from the policy and decision modules.

V1 target

scikit-learn

Logistic Regression experiment

Fits and evaluates the interpretable classifier against a rule-based baseline. No latency or accuracy claim is made here.

Evaluation

Delivery

Reproducible environments; operational services remain optional.

Docker + Compose

Local and deployment topology

Packages the backend, database and inference service for reproducible development and deployment.

V1 target

Firebase Cloud Messaging

Step-up and revocation notifications

Optional delivery channel for verification prompts and session revocation notices. Not required for the core decision path.

Planned

Nginx

TLS termination and routing

Optional reverse proxy for TLS, request limits and path routing in a deployed environment.

Planned

One verification core

Authentication, context, policy, decision and audit share one transactional backend in V1. This avoids distributed coordination before load justifies it.

Bounded inference

The ML service estimates contextual risk over a narrow input contract. It cannot read policy authority or grant access by itself.

Evidence, not truth

Client-submitted GPS, QR and device data are treated as evidence. The design does not assume they are impossible to spoof.

12Inspect the framework

Inspect the decision, not just the badge.

TrustAccess makes identity, context and policy visible in one verification path. Explore the architecture, test a deterministic scenario, or examine the research method — including its limits.

Open decision simulatorInspect architecture

No account required · illustrative simulations

Three ways in

01Architecture mapSee what each layer owns and what crosses a boundary.02Verification pipelineTrace every stage from request to auditable decision.03Research & evaluationInspect the method, features and what remains unmeasured.

Research framework · illustrative Smart Campus configurations

Status reflects V1 intent, not a deployment claim