Integrating with AURA

1. Overview — how AURA integrates

AURA lets a passenger move through the airport using one verified identity, created once and reused at security and boarding. To do that, AURA must coordinate with the systems an airport already depends on — but without leaking personal data or losing control of it.

The core idea: tokens, not identities

AURA hands partner systems a meaningless claim-ticket (a token) — never a passenger's real identity or biometric data. Partners coordinate about a passenger using that token; only AURA's on-premise vault at KSIA can resolve a token back to a real person.

The promise every integration keeps

Every connection — without exception — is:

• Authenticated — mutual; AURA knows which system is calling and the partner knows it's really AURA.
• Encrypted — protected in transit, always.
• Token-based — exchange tokens/references, not raw personal data, wherever possible.
• Audited — every exchange writes a tamper-evident audit record (referenced by token).

Two hard lines that never move

1. Biometric templates never cross an external boundary. The only system that touches them is the on-premise matching engine at KSIA.
2. Raw identity stays on-prem. Partners receive tokens; only the KSIA vault resolves a token to a person.

2. Integration landscape — partner-facing systems & connectors

AURA defines eight integration points (connectors). Six are implemented as working, contract-shaped mocks in the current demonstrator (INT-1, 2, 3, 5, 6, 7); INT-4 and INT-8 are designed and scheduled. Sensitivity refers to the data crossing that boundary.

🟢 non-personal / operational  ·  🟡 tokenized references  ·  🟠 minimal personal data (regulated)  ·  🔴 biometric (never crosses by default)

3. Minimum credible pilot integration set

To run a realistic Terminal 6 pilot, AURA needs the smallest set that can anchor identity to a real document, validate the journey against a real booking, give gates correct flight context, authenticate staff, and make a (simulated) gate decision:

4. Token-based interface principles

These reusable contract "shapes" let every partner connect the same safe way. Shapes below are illustrative — exact field names are confirmed per partner during onboarding.

P1 · Token issuance & resolution (the core mechanism)

1. AURA enrolls a passenger and mints an opaque token (e.g. tok_ab12cd34).
2. AURA shares only the token with partners.
3. When a partner calls back, AURA resolves the token on-prem to act.
4. Tokens are scoped (what they can do) and short-lived (auto-expire).

P2 · Inbound validation (e.g. DCS booking check)

P3 · Outbound status push (e.g. boarding result → DCS)

P4 · Verification result (gate ↔ matching engine, on-prem only)

P5 · Webhook / event subscription (e.g. AODB flight updates)

AURA subscribes to flight/gate change events. Each event is non-personal (🟢), validated, and applied to gate context.

Cross-cutting contract rules (every pattern)

Synchronous vs asynchronous

5. Partner-by-partner requirements

For each integration: what it's for, what AURA sends out and receives in, the contract pattern that applies, and the firm rule on raw identity / biometrics.

Data-exchange matrix (at a glance)

6. Security requirements — auth, encryption, audit, trust boundaries

Every door is a potential break-in point, so each one gets the same strong locks. These rules apply to all integrations.

Authentication & encryption (what we ask of partners)

• Mutual authentication — partner identity and AURA identity are both verified on every connection (e.g. mutual TLS and/or signed tokens).
• Encryption in transit, always — modern TLS; no plaintext, no exceptions.
• Per-partner credentials — every partner has its own keys; any one can be revoked without affecting others.
• Least-privilege scopes — a partner's credentials can do only their integration's job.
• Short-lived tokens — tokens expire quickly; a leaked token soon becomes useless.
• Key rotation — credentials and keys are rotatable on a defined schedule and on demand.

Audit & logging expectations

• Every exchange is audited — AURA writes a tamper-evident audit entry for each call, referenced by token, never by raw identity.
• No personal data in logs or URLs — identifiers travel as tokens in the request body; logs hold tokens and outcomes only.
• Correlation IDs — each request carries a correlation/idempotency id so both sides can trace a transaction without sharing personal data.
• Anomaly alerting — unusual call patterns (volume, timing, scope) raise alerts; partners may be rate-limited.

Trust-boundary rules

7. Error-handling & fallback expectations

Partners will sometimes be slow, down, or wrong. AURA must never strand a passenger and never make an unsafe decision because a partner failed.

Core failure principles

1. Fail safe, not open. If a security-relevant check can't complete, the result is REFER to a human — never an automatic ALLOW.
2. 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.
3. Human fallback owns the edge cases. Airport operations + airline/customer service handle fallbacks, with manual override and full audit.

Standard error contract

Every interface returns { error, code, retryable: true|false } so AURA can consistently decide retry (transient) vs. REFER/escalate (non-retryable).

Per-integration fallback behavior

8. Phase 1 vs later integration scope

Build the minimum credible set first; add the rest as the platform matures.

Later phases

• Deeper border/government interoperability
• Airline-alliance / multi-airline integration
• Cross-airport identity reuse (with consent + governance)
• Richer partner ecosystem (lounges, bag-drop, retail) — all token-based

9. Test / sandbox expectations

Integration is validated against contracts before any production data is exchanged. The current AURA demonstrator already runs working, contract-shaped mocks of INT-1, INT-2, INT-3, INT-5, INT-6 and INT-7, so flows can be exercised end-to-end safely.

What AURA provides to partners

• Versioned contract definitions for each relevant interface (request/response shapes, error contract).
• A sandbox environment where partner endpoints are mocked to those contracts.
• Observable request/response traces and audit entries for every simulated call.
• Test scenarios including success, partner-down (fallback), and forbidden-field (trust-boundary) cases.

What AURA asks of partners

• A non-production / sandbox endpoint and test credentials per integration.
• Representative non-personal / synthetic test data (no real passenger data in test).
• Confirmation of contract field names, scopes, token scheme, and error semantics.
• Agreement on idempotency keys, retry/backoff behavior, and rate limits.
• A technical point of contact for joint testing and issue triage.

10. Onboarding checklist

A practical sequence for a partner to begin integration. Items a partner must confirm are marked.

A · Scope & contacts

• Confirm which integration(s) you own (INT-1 / INT-2 / INT-3 / INT-5 / INT-7).
• Confirm Phase 1 participation and whether INT-4 (gov/border) is mandated for the pilot.
• Name technical, security, and business points of contact.

B · Interface & contracts

• Agree the versioned contract (fields, scopes, error shape) for each interface.
• Confirm the token scheme (preferred) or reference contract (e.g. booking token vs PNR).
• Agree sync vs async behavior, idempotency keys, retry/backoff, and rate limits.

C · Security

• Exchange and validate mutual-authentication material; confirm encryption standards.
• Provision per-partner credentials and least-privilege scopes; agree key-rotation policy.
• Confirm no personal data in URLs/logs; agree correlation-ID convention.

D · Test & sandbox

• Provide sandbox endpoint + test credentials; supply synthetic test data.
• Run contract tests, then connectivity/auth tests, then fallback & error scenarios.
• Validate audit/trace visibility on both sides.

E · Go-live readiness

• Confirm SLAs, support/escalation paths, and incident handling.
• Confirm fallback ownership for the relevant flow (ops / customer service).
• Complete privacy/regulatory sign-off for any regulated data (with KSIA/authorities).

11. Open questions for partner workshops

These are the items we expect to resolve with each partner. AURA proposes a privacy-first default for each; the workshop confirms or adjusts it.

This kit is grounded in AURA's Stage 6 Integration Readiness design and the working connector mocks in the current demonstrator. Field names and contract details are illustrative and are confirmed per partner during onboarding. Biometrics remain simulated and AI remains limited to two read-only features in this phase; neither is affected by any integration described here.