Integrating your DCS with AURA
Automated Universal Recognition Architecture · KSIA Terminal 6
How to use this edition. This is the airline-focused cut of AURA's partner kit. It zooms
in on the one integration an airline owns — the Departure Control System (INT-1) — plus the
booking-token, check-in and boarding flows that touch it. It is a starting point for discussion,
not a contract. In this phase biometrics are simulated and the DCS is mocked to the
contracts below, so shapes and flows can be validated before any production data is exchanged.
For the full cross-partner picture, see the full partner kit.
1. What AURA asks of an airline
AURA lets a passenger move through KSIA Terminal 6 on one verified identity, created once at enrollment and reused at security and boarding. The airline's role is narrow and well-bounded: confirm a booking is valid, and receive boarding status back — all of it coordinated through opaque tokens, never raw passenger identity or biometrics.
The core idea: a booking token, not a passenger record
AURA hands your DCS a meaningless claim-ticket (a token) and coordinates about a passenger using that token. Only AURA's on-premise vault at KSIA can resolve a token back to a real person. Your DCS never needs — and AURA never sends — a name, document number, or biometric.
The boarding-pass analogy. A boarding pass barcode is just a reference; the gate scanner
reads "this reference is valid for this flight" without re-reading the passport. AURA's booking
token works the same way — a reference both sides trust, with the real identity kept on-prem.
YOUR AIRLINE AURA (KSIA)
┌──────────────┐ booking token ┌─────────────────────────┐
│ Reservation │ ◄───────────────► │ Integration layer │
│ / DCS │ validity / status │ (speaks in tokens) │
└──────────────┘ └──────────┬──────────────┘
│ resolve token
▼ (ON-PREM ONLY)
┌──────────────────┐
│ KSIA VAULT │
│ identity+template│
└──────────────────┘
The promise on every call
- Authenticated — mutual; your DCS knows it's really AURA and AURA knows it's really you.
- Encrypted — modern TLS in transit, always.
- Token-based — booking tokens and references, not raw passenger data.
- Audited — every booking check and boarding push writes a tamper-evident record, referenced by token.
2. DCS integration (INT-1) at a glance
INT-1 · Airline Reservation / Departure Control System (DCS)Phase 1 required
PurposeConfirm a booking is valid (paid, today, this terminal); receive boarding status back.
PatternsP1 (token issuance/resolution), P2 (inbound validation), P3 (outbound status push)
AURA → DCSbooking token; boarding result
{ booking_token, status:"boarded", timestamp }
DCS → AURA{ valid, flight, seat, status }
You provideendpoint(s), per-partner credentials, booking-token scheme (preferred) or PNR contract, idempotency support
Hard ruleNo raw passenger identity required; prefer an airline-issued booking token over a raw PNR; no biometrics ever.
INT-1 is the only AURA integration an airline owns. It is in the minimum credible pilot set — without it, a journey cannot be validated against a real booking. The other implemented connectors (airport AODB, document auth, staff SSO, on-prem matching, notification) are owned by the airport, a document provider, or are internal to KSIA.
Where INT-1 sits. Implemented connectors in this phase: INT-1 (your DCS),
INT-2 (airport AODB), INT-3 (document auth), INT-5 (staff SSO), INT-6 (matching engine,
on-prem & simulated), INT-7 (notification). INT-4 (gov/border) and INT-8 (analytics) are
designed but not built, and are out of the airline's lane.
3. Booking & token flows
These are the reusable contract "shapes" that govern how a booking is referenced and resolved. Field names below are illustrative and confirmed with your team during onboarding.
P1 · Token issuance & resolution (the core mechanism)
- AURA enrolls a passenger and mints an opaque token (e.g.
tok_ab12cd34) tied to a booking. - AURA shares only the token with your DCS — never the passenger's identity.
- When your DCS calls back (or AURA calls you), the token is resolved on-prem to act.
- Tokens are scoped (what they can do) and short-lived (auto-expire).
P2 · Inbound booking validation (AURA → DCS, synchronous)
Request
{ booking_token, flight_number, date }
Response{ valid: true, flight, seat, status }
WhenAt enrollment / check-in, to anchor the journey to a real booking
TimingSynchronous — must answer quickly so the passenger isn't kept waiting
P3 · Outbound boarding-status push (AURA → DCS, asynchronous)
Payload
{ booking_token, status: "boarded", timestamp }
BehaviorIdempotent (safe to retry); every push audited; queued if your DCS is briefly unavailable
WhenAfter a successful (simulated) boarding decision at the gate
Booking-identifier preference
| Option | AURA's stance | Why |
|---|---|---|
| Airline-issued booking token | Preferred | Opaque, scoped, revocable; minimizes data crossing the boundary |
| Raw PNR reference | Only if unavoidable | Acceptable as a fallback contract, but a PNR is more sensitive and longer-lived |
| Passenger name / document # | Never | Forbidden field — blocked at the boundary (see §7) |
4. Check-in & boarding status exchanges
Mapping the airline-touching moments of a passenger journey onto the DCS exchanges above.
ENROLL / CHECK-IN SECURITY BOARDING
┌───────────────────┐ ┌───────────────────┐
│ AURA → DCS (P2): │ (on-prem gate │ gate decision │
│ validate booking │ decision, INT-6, │ (INT-6, simulated)│
│ by booking_token │ no DCS call) │ │ │
│ │ │ │ ▼ │
│ ▼ │ │ AURA → DCS (P3): │
│ DCS → AURA: │ │ push "boarded" │
│ {valid,flight, │ │ by booking_token │
│ seat,status} │ │ (async, idempot.)│
└───────────────────┘ └───────────────────┘
| Journey moment | Airline exchange | Direction / timing | Data crossing |
|---|---|---|---|
| Enrollment / check-in | Validate booking (P2) | AURA → DCS · sync | booking token + flight/date → validity, flight, seat |
| Security checkpoint | None — gate decision is on-prem (INT-6) | n/a | none crosses the airline boundary |
| Boarding | Push boarding result (P3) | AURA → DCS · async | booking token + status + timestamp |
Key design choice. The actual identity decision at security and boarding is made by
the on-prem matching engine (INT-6) — it does not call your DCS. Your DCS is involved only
to validate the booking up front and to receive the boarding outcome after. That keeps
your systems off the latency-critical path and makes a slow DCS unable to strand a passenger at a gate.
5. Failure & fallback behavior
Your DCS will sometimes be slow, down, or return an error. AURA is designed so that this never strands a passenger and never produces an unsafe decision.
Core failure principles
- Fail safe, not open. If booking validity can't be confirmed, the result is REFER to a human — never an automatic ALLOW.
- Gates keep working. Because the gate decision is on-prem (INT-6), a DCS outage doesn't stop checkpoints/boarding for already-validated journeys.
- Async never blocks. A failed boarding push is queued and retried; the passenger is unaffected.
Standard error contract
Every DCS response uses { error, code, retryable: true|false } so AURA can
consistently choose retry (transient) vs. REFER/escalate (non-retryable).
DCS-specific fallback table
| Exchange | If it fails… | AURA's fallback |
|---|---|---|
| P2 booking check (sync) | can't validate booking | REFER to airline/airport staff for a manual booking check; journey not auto-activated |
| P2 booking check (sync) | booking invalid / not found | Deterministic DENY/REFER; passenger directed to airline service desk |
| P3 boarding push (async) | push fails / DCS down | Queue + retry with backoff (idempotent); no double-boarding; passenger already cleared |
| Any | timeout / 5xx | Treat as retryable:true within limits, then escalate to human fallback |
The promise to your operation. A DCS outage degrades gracefully into an
airline/airport-staffed manual process — it never denies a legitimate passenger silently and
never auto-allows an unsafe one.
6. Auth, audit & token-handling rules
Authentication & encryption (what AURA asks of your DCS)
- Mutual authentication on every connection (e.g. mutual TLS and/or signed tokens).
- Encryption in transit, always — modern TLS; no plaintext, no exceptions.
- Per-partner credentials — your airline has its own keys; revocable without affecting others.
- Least-privilege scopes — your credentials can do only the INT-1 job (validate booking / receive status).
- Short-lived tokens — booking tokens expire quickly; a leaked token soon becomes useless.
- Key rotation — keys are rotatable on schedule and on demand.
Token-handling rules (airline side)
- Treat the booking token as opaque — don't parse, enrich, or persist it beyond what the flow needs.
- Tokens go in the request body, never in URLs or logs.
- Honor scope & expiry — reject expired or out-of-scope tokens.
- Idempotency keys on writes — so a retried boarding push is never applied twice.
- Correlation IDs — each call carries one so both sides can trace a transaction without sharing personal data.
Audit & logging expectations
- Every exchange is audited — AURA writes a tamper-evident entry per booking check and boarding push, referenced by token.
- No personal data in logs or URLs — logs hold tokens and outcomes only.
- Anomaly alerting — unusual call patterns raise alerts; partners may be rate-limited.
7. Trust boundary & forbidden fields
Your DCS sits on the untrusted side of AURA's boundary. AURA validates everything inbound and resolves tokens to identity only on-prem.
── UNTRUSTED (your DCS) ──────────────┊── TRUSTED (AURA) ─────────────
booking checks / boarding pushes ┊ integration layer (validates)
speak only in tokens ┊ │
┊ ▼ resolve token (on-prem)
┊ KSIA vault (most trusted)
Forbidden fields — enforced, not just stated. AURA's integration layer actively
blocks a fixed set of fields from ever crossing to an external connector like your DCS.
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.
| Rule | Plain English (airline view) |
|---|---|
| No biometrics outbound | Templates/images never reach your DCS — ever. |
| Tokens, not identities | You coordinate via booking tokens; the token↔passenger map stays on-prem. |
| Inbound validation | AURA treats all DCS responses as untrusted and validates before use. |
| Minimize what you send | Prefer booking token over PNR; never name or document number. |
8. What's real today vs simulated
| Aspect | State in this phase |
|---|---|
| DCS integration contract (INT-1) | Real, working contract — runs as a contract-shaped mock you can exercise end-to-end |
| Booking token / boarding-status flows | Real flows against the mocked DCS (no production booking data) |
| Biometric capture & matching (INT-6) | Simulated — on-prem engine returns a deterministic decision; no real biometrics |
| Live passenger / production booking data | Not used — synthetic / non-personal test data only |
| Gov/border (INT-4), analytics (INT-8) | Designed, not built — out of the airline lane this phase |
Honest framing. This is an integration blueprint and demonstrator, not a live pilot.
It lets your team validate the INT-1 contract, token handling, and fallback behavior before any
real booking data is ever exchanged.
9. Sandbox & airline onboarding
What AURA provides you
- Versioned contract definitions for INT-1 (booking validation + boarding push + error contract).
- A sandbox where your DCS is mocked to those contracts, so flows run end-to-end safely.
- Observable request/response traces and audit entries for every simulated call.
- Test scenarios: success, DCS-down (fallback), and forbidden-field (trust-boundary) cases.
What AURA asks of you
- A non-production / sandbox DCS endpoint and test credentials.
- Representative non-personal / synthetic test bookings (no real passenger data).
- Confirmation of field names, scopes, booking-token scheme, and error semantics.
- Agreement on idempotency keys, retry/backoff, and rate limits for the boarding push.
- A technical point of contact for joint testing and issue triage.
Airline onboarding checklist
- Confirm INT-1 ownership and Phase 1 participation.
- Agree the versioned INT-1 contract (fields, scopes, error shape).
- Confirm booking-token scheme (preferred) vs PNR contract.
- Agree sync booking-check timing and async boarding-push idempotency/retry.
- Exchange mutual-auth material; provision per-partner credentials & scopes; agree key rotation.
- Run contract → connectivity/auth → fallback & forbidden-field tests.
- Confirm SLAs, support/escalation, and fallback ownership (airline service desk).
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 airline teams
The items AURA expects to resolve with your team. A privacy-first default is proposed for each; the workshop confirms or adjusts it.
| # | Open question | AURA's proposed default |
|---|---|---|
| 1 | Booking identifier scheme? | Airline-issued booking token; PNR reference only if unavoidable |
| 2 | Booking-check timing budget (sync)? | Fast enough to keep enrollment/check-in seamless; agreed SLA |
| 3 | Token lifetime & scope for the DCS? | Short (minutes–hours), single-scope (validate / receive status) |
| 4 | Boarding-push retry & idempotency? | Exponential backoff + idempotency keys; no double-boarding |
| 5 | Contract style? | Versioned REST for checks; async push for boarding status |
| 6 | Auth mechanism for INT-1? | Mutual TLS and/or signed short-lived tokens; per-partner keys |
| 7 | Status vocabulary? | Minimal set (e.g. boarded); agreed during onboarding |
| 8 | Fallback ownership when DCS is down? | Airline service desk + airport ops, with manual override & audit |
| 9 | SLAs, support & incident escalation? | Agreed per airline during onboarding |
| 10 | Future alliance / multi-airline reuse? | Out of Phase 1; token-based design keeps it open for later |
In one sentence. For airlines, AURA touches exactly one integration — your DCS (INT-1) —
through a versioned, token-based, authenticated, encrypted, audited contract that validates a
booking up front and receives the boarding outcome after, while raw identity and biometrics stay
on-prem and any failure fails safe to human fallback.
Airline edition of AURA's partner onboarding kit, grounded in Stage 6 Integration Readiness and the working INT-1 connector mock 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.