Airport Biometric Boarding Architecture Diagram: Edge Capture, Session Match & Privacy

An airport biometric boarding architecture that ships must answer three questions: where the face credential lives between trips, how a short-lived session reaches the departure airport without a permanent central gallery, and what the biometric e-gate does when a live capture must prove 1:1 identity while the airline Departure Control System (DCS) validates the boarding pass in the background. India’s Digi Yatra programme is a useful production reference — not a global mandate. MoCA’s Digi Yatra Guidelines and the Digi Yatra Foundation AWS case study describe the same privacy-shaped flow: an SSI travel credential in the passenger wallet, consent share to an airport verifier, edge live-face match, and a 24-hour purge after departure. Digi Yatra is India-specific, voluntary, and face-only inside DYBBS; immigrations ABC is isolated from DYBBS — keep those systems separate on the diagram.

Multi-checkpoint ID friction at airports

Classic departure flows force the same passenger to present identity and travel documents at entry, check-in, security, and boarding. Each stop is a manual inspection budget — Digi Yatra Foundation’s AWS case study cites roughly 15 seconds per traditional entry step collapsing to about 5 seconds once face becomes the single token and the boarding pass is validated digitally. The architectural goal is not “one more scanner”; it is one consented credential path that removes repeated paper checks while keeping PII under passenger control.

Digi Yatra’s Central Ecosystem and apps follow W3C / SSI ideas: the passenger holds credentials; stakeholders receive only what is shared. On the diagram, the phone wallet is the durable store; airport nodes hold journey-scoped copies.

Enrollment: e-KYC reference face + liveness selfie → wallet VC

Enrollment creates the Digi Yatra ID travel credential before the travel day. On the AWS-described path, Amazon Cognito signs the user in with an OTP delivered through Amazon SNS. The passenger then completes Aadhaar validation — direct Aadhaar validation or DigiLocker Aadhaar e-KYC. The app extracts a reference face from the e-KYC payload, prompts a liveness selfie, and matches selfie to reference face. On success, AWS Lambda-backed flows generate and later verify verifiable credentials stored encrypted in the smartphone wallet.

MoCA Guidelines align: liveness selfie matched to the ID-database face; credential stored as a verifiable Digital Travel Credential in the secure wallet. Aadhaar biometrics captured for identity validation must not be stored or reused under the Aadhaar Act — Digi Yatra keeps a travel face token, not UIDAI core biometrics. Digi Yatra itself is face-only (no iris/fingerprints). After creation, the passenger uploads or scans a boarding pass; Guidelines warn against embedding Digi Yatra ID material in ticket barcodes.

Pre-travel consent share to the departure airport verifier

The passenger explicitly consents to share ID + travel credentials with the departure airport ahead of STD. AWS describes a “ready to fly” status, an updated digital boarding pass in-app, and delivery to the departure airport verifier node. Guidelines require informing the user that face data is shared for airport checkpoints, with separate opt-in (and one-click opt-out) for value-added partner services. Architecturally this is a short-TTL verifier session — not national-gallery enrollment. The wallet stays long-lived; the passenger controls whom, what, and when (airlines/OTAs, airports, and optionally immigration authorities for international travel).

E-gate: live face 1:1 match + airline DCS validation

At the airport entry biometric e-gate, the passenger opens the app and scans the gate QR (AWS narrative). The gate path retrieves shared credentials, captures a live face, and performs a 1:1 match against the shared ID face while boarding-pass validation runs against the airline Departure Control System in the background. Guidelines describe DYBBS e-gate checks as: (1) e-ticket/boarding pass vs airline DCS, (2) real-time biometric validation against Digi Yatra ID travel credentials, and (3) time-window checks for airport entry. On success the flap opens and a journey Passenger Live Dataset is created for later checkpoints.

CISF handles exceptions (amber/red and failed matches → manual ID check). A parallel non-biometric lane remains: barcode/QR plus manual ID — Digi Yatra is voluntary.

Passenger Live Dataset across checkpoints

After successful entry, DYBBS stores a journey-scoped Passenger Live Dataset: check-in fields (PNR, name, flight number, date/time, origin/destination, sequence, seat), the passenger’s face as a digital template, and a unique passenger identifier. That dataset is reused as the single token — biometrics or barcode/QR/BCBP — at subsequent airport checkpoints through boarding (check-in/CUSS, bag drop, security/frisking approach, boarding gate).

That is the edge session-match idea: one consented airport-side template fan-out, not re-enrollment at every door. The Live Dataset is real temporary airport state — which is why the 24-hour purge belongs on the same diagram as the privacy claims.

Federated airport edge vs central ecosystem

AWS hosts Central Ecosystem services (Cognito, SNS OTP, Lambda VC generate/verify) and the apps. Airport FR hardware and local DYBBS are federated — each airport runs its own stack (Express Computer interview, Dec 2024). Hedge that interview’s “no databases / no PII stored” framing: Guidelines still define Passenger Live Datasets, temporary facial storage until purge, and non-biometric audit logs. Draw central cloud and airport edge FR as separate swimlanes. Scale figures differ: AWS 4.5M+ users vs interview ~7.5M registered — label the latter as interview, not interchangeable with AWS.

Privacy controls: face-only, consent, 24-hour purge

Three controls dominate an honest architecture diagram:

• Face-only in Digi Yatra — Guidelines: no iris/fingerprints (or other non-face biometrics) collected or stored in Digi Yatra. Do not draw multimodal ABIS-style capture into this box.
• Consent + wallet custody — durable VCs on the phone; airport receives a short-period verifier copy after explicit share; passenger controls recipients and optional VAS/marketing consents separately.
• 24-hour purge — Guidelines (prefer this wording): facial data purged from DYBBS 24 hours after take-off/departure. AWS: credentials at the departure airport verifier purged within 24 hours after flight departure. Guidelines also allow travel logs without biometric data for mandated audits, and note purge settings may be adjusted for security requirements — so the diagram’s purge timer is policy-backed, not “data never existed at the airport.”

Aadhaar e-KYC is identity validation only; core Aadhaar biometrics must not be stored or reused. Hotel and international expansion appear as AWS/interview roadmap vision — not live product unless a primary source says so.

What this architecture is — and is not

Is: an India Digi Yatra reference architecture for privacy-shaped airport biometric boarding — SSI wallet VCs, consent share to a departure airport verifier, live-face 1:1 at the e-gate with airline DCS validation, Passenger Live Dataset reuse across checkpoints, federated airport FR edge, and a 24-hour facial purge after departure.

Is not: a universal ICAO/IATA mandate; a multimodal iris/fingerprint Digi Yatra store; a claim that Aadhaar core biometrics live in Digi Yatra; an immigrations ABC system (Guidelines: immigrations is completely isolated from DYBBS); or a place to invent matcher FAR/FRR numbers the primary sources do not publish. International One ID alignment and hotel flows are roadmap/vision in secondary and AWS narrative — keep them labeled as such on the diagram.

FAQ

Is Digi Yatra face-only?

Yes for Digi Yatra / DYBBS: Guidelines ban collecting/storing iris, fingerprints, or any non-face biometrics in Digi Yatra. Immigrations ABC is isolated and may use other modalities under immigrations rules — not Digi Yatra storage.

Where do biometrics live?

Long-lived VCs (including the face token) live encrypted in the smartphone wallet. After consent, the departure airport verifier holds a short-lived copy; DYBBS builds a Passenger Live Dataset (face template + PNR + unique ID) for checkpoint reuse, then purges facial data 24 hours after take-off/departure. Aadhaar e-KYC biometrics must not be stored or reused.

What is the 24h purge?

Guidelines: purge facial data from Airport DYBBS 24 hours after take-off/departure. AWS: airport-verifier credentials purged within 24 hours after flight departure. Non-biometric travel logs may remain for mandated audits.

Conclusion

Draw the custody story: wallet VC → consent share → airport verifier → e-gate live 1:1 + DCS → Passenger Live Dataset fan-out → 24h purge, plus a non-biometric lane and federated airport FR beside central SSI services. Digi Yatra is the India reference — MoCA for face-only and purge wording, AWS for Cognito/SNS/Lambda and ~15s→~5s entry times — not a global standard, and not a place for immigrations or Aadhaar-gallery claims the sources do not support.