Integrating AURA with airport operations
Automated Universal Recognition Architecture · KSIA Terminal 6
How to use this edition. This is the airport-focused cut of AURA's partner kit. It zooms in
on what the airport owns — flight & gate context from the AODB (INT-2) and
staff identity / SSO (INT-5) — plus the on-prem trust boundary that keeps biometrics inside
KSIA, and how the system stays resilient and fail-safe. It is a starting point for discussion,
not a contract. In this phase biometrics are simulated and partner systems are mocked
to the contracts below. For the full cross-partner picture, see the
full partner kit.
1. What AURA asks of the airport
AURA lets a passenger move through Terminal 6 on one verified identity, reused at security and boarding. For that to be safe and operationally correct, AURA needs two things from the airport: accurate flight & gate context (so gates show the right information) and trustworthy staff identities (so role-based access controls work). It also relies on the airport hosting the on-premise trust boundary where biometrics live.
The airport owns two integrations
- INT-2 · AODB — flight schedules, gates, delays, terminal status (non-personal operational data).
- INT-5 · Staff SSO — authenticate AURA staff so RBAC knows which officer is acting.
It also hosts INT-6 — the on-prem matching engine (simulated this phase) — inside the airport's trusted environment. INT-6 is not a partner integration; it is the crown-jewels component that never leaves KSIA.
AIRPORT (KSIA) AURA
┌──────────────┐ flight/gate events ┌─────────────────────────┐
│ AODB │ ─────────────────────► │ Integration layer │
│ (INT-2) │ (non-personal, 🟢) │ (validates inbound) │
└──────────────┘ │ │
┌──────────────┐ staff identity+role │ │
│ Staff IdP │ ─────────────────────► │ RBAC │
│ SSO (INT-5) │ └──────────┬──────────────┘
└──────────────┘ │
┌────────────────────────────────────┐ on-prem ▼
│ Matching engine (INT-6, simulated) │ ◄── ON-PREM TRUST BOUNDARY
│ templates never leave KSIA 🔴 │
└────────────────────────────────────┘
Implemented scope this phase. INT-1 (airline DCS), INT-2 (AODB), INT-3 (document
auth), INT-5 (staff SSO), INT-6 (matching, on-prem & simulated), INT-7
(notification). INT-4 (gov/border) and INT-8 (analytics) are designed but not built.
2. Flight & gate context (INT-2 · AODB)
INT-2 · Airport Operational Database (AODB)Phase 1 required
PurposeFlight numbers, times, gates, delays, terminal status so gates and staff see correct context.
PatternsP5 (webhook / event subscription) and/or a read API
AODB → AURAflight & gate events and schedule reads — non-personal only
You provideevent feed or polling API, schema, change-notification mechanism
Hard ruleLowest-risk integration — it must contain no passenger personal data.
The AODB is AURA's source of operational truth. It is the safest integration precisely because it carries only non-personal data: a gate change or a delay, never a name.
What AURA consumes from the AODB
| Data | Used for | Sensitivity |
|---|---|---|
| Flight number, scheduled / estimated times | Anchoring a journey to the right flight; gate displays | 🟢 non-personal |
| Gate & stand assignment | Directing passengers; gate context for the boarding decision | 🟢 non-personal |
| Delays / status changes / cancellations | Operational triggers (see §3); keeping context fresh | 🟢 non-personal |
| Terminal status | Overall operational picture for Terminal 6 | 🟢 non-personal |
3. Operational triggers
AODB events don't just populate displays — they drive AURA's operational behavior. Each event is non-personal, validated on arrival, then applied to gate context.
AODB EVENT AURA RESPONSE
─────────────────────────────────────────────────────────────
gate change ──► update gate context; redirect guidance (via INT-7)
delay / retime ──► refresh flight context; adjust passenger messaging
cancellation ──► flag journeys on that flight; route to staff handling
flight closed ──► stop accepting boarding for that flight at the gate
stale / no update ──► mark context "stale"; staff verify gate/flight manually
| Trigger | Operational effect | Fail-safe note |
|---|---|---|
| Gate reassignment | Gate context updated; passengers re-guided | If event missed, staff override; last-known flagged stale |
| Delay / schedule change | Context refreshed; messaging adjusted | Non-blocking; gate decision (INT-6) unaffected |
| Cancellation | Affected journeys flagged for staff | Never auto-denies a passenger silently — routed to human |
| Boarding closed | Gate stops accepting that flight | Deterministic; manual override possible with audit |
4. Staff SSO & RBAC touchpoints (INT-5)
INT-5 · Staff Identity / SSOPhase 1 required
PurposeAuthenticate AURA staff (which officer is logging in?) to drive role-based access control.
PatternsFederated sign-on (e.g. OIDC/SAML), role / group assignment
IdP → AURAstaff identity + role assignment
You provideIdP metadata, role/group mapping, MFA expectations
Hard ruleThis is staff identity, not passenger identity. No passenger data flows here.
How RBAC uses staff identity
Once a staff member is authenticated via your IdP, AURA maps them to a role, and every sensitive action is checked against that role's capabilities on the server side — not just hidden in the UI. A few concrete examples from the demonstrator:
| Capability | What it gates | Roles that hold it |
|---|---|---|
journey.link | Link/check-in a passenger journey | enrollment agent, operations supervisor |
ai.configure | Toggle the AI assistive features (e.g. kill switch) | security admin (separation of duties) |
Separation of duties is enforced. A role that can run the passenger journey cannot also
reconfigure AI controls, and vice-versa. RBAC is checked server-side on every sensitive call —
an unauthorized action is denied and audited, even if a button were somehow reachable.
What AURA asks of the airport IdP
- Federated sign-on (OIDC/SAML) with IdP metadata exchanged during onboarding.
- Explicit role / group mapping so AURA roles map cleanly to airport staff groups.
- MFA expectations for sensitive roles.
- A break-glass path (dual-control, alarmed, audited) for SSO outages — see §6.
5. On-prem trust boundary (INT-6)
The single most important architectural principle for the airport: biometrics never leave KSIA. The matching engine that compares a live capture to a stored template runs on-premise, inside the airport's trusted environment.
INT-6 · Matching Engine (on-prem, simulated this phase)Phase 1 (simulated)
PurposeCompare a live capture to a stored template — the actual gate decision.
ContractRequest
{ identity_ref, live_capture, stage } → { decision, confidence, reason }
Hard ruleTemplates & results never leave KSIA. A real engine slots into this same contract later with no re-architecture.
── UNTRUSTED (partners) ──────────────┊── TRUSTED (AIRPORT / AURA) ───────
airline DCS / doc provider / cloud ┊ integration layer (validates)
┊ │
┊ ▼ resolve token (on-prem)
┊ ┌──────────────────┐
┊ │ KSIA VAULT │ identities,
┊ │ + INT-6 matching │ templates,
┊ │ (crown jewels) │ consent, audit
┊ └──────────────────┘
- Biometric templates never cross an external boundary. Only the on-prem engine touches them.
- Raw identity stays on-prem. Partners get tokens; only the KSIA vault resolves a token to a person.
- The gate decision is on-prem and synchronous. It never depends on the internet or any partner.
Why this matters to the airport. Hosting INT-6 and the vault on-prem means KSIA keeps
physical and operational control of the most sensitive data, and gate decisions keep working even
if the wider network or any partner is down.
6. Resilience & fail-safe behavior
Airport operations cannot tolerate a system that strands passengers or makes unsafe decisions when something fails. AURA is designed to fail safe, not open.
Core resilience principles
- Fail safe, not open. If a security-relevant check can't complete, the result is REFER to a human — never an automatic ALLOW.
- Gates keep working. Because the gate decision is on-prem (INT-6), a cloud or partner outage doesn't stop checkpoints/boarding for already-validated journeys.
- Human fallback owns the edge cases. Airport operations handle fallbacks with manual override and full audit.
Airport-relevant fallback table
| Integration | If it fails… | Fallback |
|---|---|---|
| INT-2 AODB | flight data stale / unavailable | Use last-known + flag "stale"; staff verify gate/flight manually |
| INT-5 Staff SSO | SSO down | Break-glass staff access (dual-control, alarmed, audited) |
| INT-6 Matching (on-prem) | low confidence / poor capture | Deterministic REFER; human officer + manual document fallback |
| INT-1 Airline DCS | can't validate booking | REFER to staff for manual booking check; journey not auto-activated |
| INT-7 Notification | delivery fails | Best-effort retry; non-blocking; passenger can use kiosk/staff |
| Network / cloud | connectivity lost | On-prem gate decisions continue; async items queue and backfill |
The promise to operations. Any partner or network outage degrades gracefully into a
human-assisted process — it never denies a legitimate passenger silently and never auto-allows an
unsafe one.
7. Forbidden fields — enforced at the boundary
Enforced, not just stated. AURA's integration layer actively blocks a fixed set of
fields from ever crossing to an external connector. If any appear, the request is rejected and
the attempt is audited. These include:
template_data, raw_image,
selfie, given_name, family_name, and
document_number. The on-prem matching engine (INT-6) is the only component
permitted to handle biometric data — and it never leaves KSIA.
For the airport, this matters most for the AODB: by design the AODB carries no passenger personal data at all, so it sits comfortably on the right side of this rule. Staff SSO (INT-5) carries staff identity only — never passenger data.
| Rule | Plain English (airport view) |
|---|---|
| No biometrics outbound | Templates/images stay inside KSIA on the on-prem engine. |
| AODB is non-personal | Flight/gate data only — never a passenger name. |
| Staff ≠ passenger | SSO carries staff identity for RBAC, not passenger identity. |
| Inbound validation | AURA treats all AODB/IdP data as untrusted and validates before use. |
8. What's real today vs simulated
| Aspect | State in this phase |
|---|---|
| AODB integration contract (INT-2) | Real, working contract — runs as a contract-shaped mock you can exercise end-to-end |
| Staff SSO & RBAC (INT-5) | Real RBAC enforced server-side; staff identity via a mocked IdP contract |
| On-prem matching (INT-6) | Simulated — deterministic decision; no real biometrics; same contract a real engine will use |
| Live operational / passenger data | Not used — synthetic / non-personal test data only |
| Gov/border (INT-4), analytics (INT-8) | Designed, not built this phase |
Honest framing. This is an integration blueprint and demonstrator, not a live pilot.
It lets airport teams validate AODB events, staff SSO/RBAC, the on-prem boundary, and fail-safe
behavior before any real operational data is exchanged.
9. Sandbox & airport onboarding
What AURA provides you
- Versioned contract definitions for INT-2 (events/read API) and INT-5 (federation + role mapping).
- A sandbox where AODB and IdP are mocked to those contracts, so flows run end-to-end safely.
- Observable request/response traces and audit entries for every simulated event and login.
- Test scenarios: success, AODB-stale, SSO-down (break-glass), and forbidden-field cases.
What AURA asks of you
- A non-production AODB feed/endpoint and a test IdP (or sandbox tenant) with test credentials.
- Representative non-personal / synthetic flight, gate and staff data.
- Confirmation of AODB schema & change-notification mechanism, and IdP role/group mapping.
- Agreement on break-glass procedure, MFA expectations, and stale-data handling.
- A technical point of contact for joint testing and issue triage.
Airport onboarding checklist
- Confirm INT-2 and INT-5 ownership and Phase 1 participation.
- Agree the versioned AODB contract (events vs read API, schema, change notifications).
- Exchange IdP metadata; agree role/group mapping and MFA for sensitive roles.
- Confirm on-prem hosting arrangement for INT-6 / vault (trust boundary).
- Agree resilience behavior: stale-data flagging, break-glass, manual override + audit.
- Run contract → connectivity/auth → fail-safe & forbidden-field tests.
- Confirm SLAs, support/escalation, and fallback ownership (airport operations).
Staged validation. Contract test (mocked) → connectivity & auth test (real endpoints,
synthetic data) → controlled pilot (real data, limited gates, human fallback staffed). No step
advances until the previous passes.
10. Workshop questions for airport teams
The items AURA expects to resolve with the airport. A privacy-first / resilient default is proposed for each; the workshop confirms or adjusts it.
| # | Open question | AURA's proposed default |
|---|---|---|
| 1 | AODB delivery: events or read API? | Event/webhook feed for changes + read API for reconciliation |
| 2 | AODB change-notification mechanism? | Push events on gate/delay/status change; agreed schema |
| 3 | Stale-data handling? | Use last-known, flag "stale", staff verify manually |
| 4 | SSO protocol & role mapping (INT-5)? | OIDC/SAML federation with explicit role/group mapping + MFA |
| 5 | Break-glass for SSO outage? | Dual-control, alarmed, fully audited emergency access |
| 6 | On-prem hosting for INT-6 / vault? | Inside KSIA's trusted environment; templates never leave |
| 7 | Network-loss behavior? | On-prem gate decisions continue; async items queue + backfill |
| 8 | Auth mechanism for INT-2/INT-5? | Mutual TLS and/or signed short-lived tokens; per-partner keys |
| 9 | Fallback ownership for operations? | Airport operations, with manual override & full audit |
| 10 | SLAs, support & incident escalation? | Agreed during onboarding |
In one sentence. For the airport, AURA consumes non-personal flight/gate context from the
AODB (INT-2), authenticates staff via your SSO to drive server-enforced RBAC (INT-5), and hosts the
biometric matching engine and vault on-prem (INT-6) so the most sensitive data never leaves KSIA and
gate decisions keep working — failing safe to airport-operated human fallback whenever anything breaks.
Airport / AODB edition of AURA's partner onboarding kit, grounded in Stage 6 Integration Readiness and the working INT-2, INT-5 and INT-6 connector mocks in the current demonstrator. Connector scope this phase is INT-1, 2, 3, 5, 6 and 7. Field names and contract details are illustrative and confirmed per partner during onboarding. Biometrics remain simulated; this is an integration blueprint, not a live pilot.