Trip.com autofills flight bookings with wallet-based identity

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Hopae's case study: Trip.com is using wallet-based digital identity to autofill flight bookings, reducing manual entry and exposing how travel booking can be driven by verified credentials instead of typed data.

Why it matters: This matters because travel platforms, identity teams and IAM leads need to decide how far verified credentials should replace form-based identity collection across booking, check-in and downstream travel workflows.

Context

Digital identity lets a person reuse a verified credential from a mobile wallet instead of retyping identity attributes into a booking form. In travel, that changes the control point from manual data entry to credential presentation and verification, which has implications for assurance, usability and downstream document checks.

Trip.com's implementation is a practical example of consumer identity moving closer to the transaction itself. identity wallets and digital credentials stop being a separate concept and become part of the booking flow, which is why the governance question shifts from capture to trust and reuse.

Key questions

Q: How do wallet-based credentials change online identity verification?

A: Wallet-based credentials let a person present verified claims from a digital wallet instead of retyping identity data into a website or app. Verification shifts towards checking the wallet’s cryptographic proof, issuer trust, and selective disclosure, which can reduce document copying and repeated data entry while still requiring revocation, issuer validation, and fraud controls.

Q: How should travel platforms govern digital identity reuse across booking and check-in?

A: Travel platforms should govern digital identity reuse by setting assurance thresholds for each step, such as booking, payment, self-service changes, and check-in. The same account or wallet claim should not automatically satisfy every journey step. Reuse needs policy checks, step-up verification for higher-risk actions, and controls for identity binding, revocation, and shared accounts.

Q: What is the difference between a digital wallet and a passport credential?

A: A digital wallet is the container or app that stores and presents credentials, while a passport credential is one specific identity document issued by an authority. The wallet can hold many credentials and disclose selected attributes, but the passport credential is the actual signed assertion or document used for identity proofing and verification.

Q: What should teams do first before replacing form entry with verified identity?

A: Teams should first map which forms collect identity data, why each field is needed, and what trust level the process actually requires. That lets them decide whether verified identity, selective disclosure, or plain form entry is appropriate, and where fallback steps, exception handling, and fraud checks are needed before automation replaces manual input.

Technical breakdown

Wallet-based identity assertion in booking flows

A wallet-based identity flow lets a traveller present verified attributes from a mobile wallet instead of typing them into a form. The booking platform receives credential-backed data after verification, then maps it into the booking record. The important security property is that the platform is no longer relying on free-text self-assertion for fields that affect ticketing, document matching and downstream identity checks. See the Digital Identity, eID and Identity Wallets Guide.

Practical implication: Treat wallet-supplied booking attributes as verified inputs that still need clear validation, mapping and audit trails.

Interoperability across eID schemes

Interoperability means one integration can accept credentials from many national eID schemes and wallet providers without a separate point-to-point build for each source. That reduces integration sprawl, but it also pushes more weight onto credential trust policy, issuer recognition and attribute mapping rules. The operational challenge is not just connectivity, but deciding which credential types and assurance levels are acceptable for which booking actions. See the National Digital ID Schemes Map.

Practical implication: Define which eID sources are acceptable for booking, and tie each source to a specific assurance policy.

Document-light travel and downstream identity reuse

A document-light journey uses the same verified identity object across booking, check-in, visas and biometric boarding. That creates continuity, but it also extends the lifetime and value of the identity assertion across multiple trust boundaries. Once a credential is reused beyond the initial transaction, the key question becomes whether the original assurance still matches the later use case.

Practical implication: Set separate trust thresholds for booking, check-in and boarding instead of assuming one verified credential fits all steps.

NHI Mgmt Group analysis

Digital identity is moving the trust decision upstream: Booking systems no longer need to accept identity as typed input when a wallet can present a verified credential instead. That changes the control point from form validation to credential assurance, issuer trust and attribute mapping. The implication is that travel IAM must treat the booking step as part of identity governance, not just customer experience.

Interoperability is the real scaling constraint: One integration across many eID schemes matters because travel platforms cannot build and maintain bilateral trust for every market. The hard part is not technical connectivity alone; it is governing which credentials count, at what assurance level, and for which transaction types. That makes trust policy as important as user flow design.

Traveller control changes the governance model: Wallet-based sharing gives users more visibility into what they disclose, but it also introduces selective disclosure and consent semantics into a commercial workflow. Travel organisations have to govern attribute minimisation, reuse and retention together. The consequence is that consumer identity teams and IAM teams can no longer treat booking data capture as a pure application problem.

Document-light travel depends on identity continuity, not just convenience: The same credential can extend from booking into check-in and boarding, but each handoff creates a new policy decision. A credential that is good enough for booking may not be sufficient for later operational or regulatory checks. Practitioners should design step-specific assurance, not assume one verified wallet assertion fits the whole journey.

What this signals

Identity reuse is only safe when the assurance model is explicit: The moment a verified wallet credential moves from booking into later travel steps, the platform has to decide whether the original proof still holds. That means product teams and IAM teams need a shared policy for reuse, not just a smoother UX path.

Travel workflows will increasingly depend on interoperable credential acceptance rather than isolated customer profiles. The governance challenge is to make attribute mapping, consent and lifecycle rules consistent across every place the same identity assertion is consumed.

For practitioners

• Define accepted wallet credentials for each booking step Specify which eID schemes and wallet types can populate booking fields, and tie each one to a defined assurance level and transaction purpose.
• Separate booking assurance from downstream travel checks Set different policy thresholds for booking, check-in, visa handling and biometric boarding so a single verified credential is not overextended.
• Map identity attributes before autofill goes live Document which wallet attributes populate which booking fields, where normalization happens, and what exceptions require manual review.
• Audit consent, retention and reuse rules Make sure traveller-shared identity data is governed across storage, replay prevention and later reuse in adjacent travel workflows.

Key takeaways

• Wallet-based identity can reduce booking friction, but it shifts the trust decision from typed data to credential assurance and issuer policy.
• Interoperability across many eID schemes is the scaling problem that determines whether digital identity can work across travel markets.
• Practitioners need step-specific assurance rules so a verified credential is not treated as equally valid for booking, check-in and boarding.

Related NHI Mgmt Group resources: Digital Identity, eID and Identity Wallets Guide · National Digital ID Schemes Map · Citizen Digital Wallet Safety Guide

Key terms

• Digital Identity: Digital identity is the set of attributes, credentials, and access relationships used to authenticate and authorize a person, service, workload, or automated system. In security operations, it becomes the control layer that determines what can act, where it can go, and how far compromise can spread.
• Identity Wallet: An identity wallet is a user-controlled container for verified identity attributes or credentials that can be reused across applications. It aims to reduce repeated proofing and login friction, but it also concentrates trust, so issuance, revocation, and recovery controls become central to its security posture.
• Verifiable Credentials (VCs): Verifiable Credentials are digital statements that prove a claim about a person, device, or service without exposing unnecessary underlying data. They use cryptographic signatures and standardized presentation rules so a relying party can check authenticity, integrity, and issuer trust, supporting privacy-preserving identity verification across human and non-human identity flows.
• Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.