Verifiable credentials in travel: what the protocol verifies and why it matters

Every booking in the travel industry is an act of trust. A traveller trusts that the hotel is licensed. The OTA trusts that the ski school's instructors are certified. The insurer trusts that the activity operator holds valid public liability coverage. None of these trust relationships are systematically verified at the moment of booking. They are established through contracts, manual compliance processes, and the accumulated experience of long-standing commercial relationships.

This works, slowly and expensively, at the scale of the industry as it has historically operated. It does not work at the scale the AI travel era requires.

the cost of manual trust

An OTA wants to add a regional ski school network to its activity catalogue. The ski school operates across six resorts, employs forty instructors, holds sector licences in two jurisdictions, and maintains public liability insurance through a specialist sports insurer.

The OTA's compliance team requests the documentation: operating licences, instructor certifications, insurance certificates, safety inspection records, data protection registration. Each document arrives separately — some by email, some through a supplier portal, some by post. A compliance analyst reads each one. Another analyst files them. A third sets calendar reminders for renewal dates. If an instructor's certification expires mid-season and the renewal is not filed promptly, there may be a gap between the expiry and the OTA's awareness of it.

Now multiply this process by the size of a real OTA catalogue: Viator lists over 300,000 experiences. GetYourGuide lists over 140,000 activities. The manual compliance process that works for 50 suppliers does not work for 50,000. At scale, it either degrades into a checkbox exercise — did you submit the documents? yes — or it requires a compliance team so large that supplier onboarding becomes the dominant cost of operating an activity marketplace.

why the current model cannot scale to AI booking

The compliance problem is not new. What is new is AI booking.

When a human travel agent books an activity, there is an implicit layer of judgment: they know the suppliers they work with, they have a sense of which ones are well-run, and they apply informal quality filters that never appear in a compliance database. When an AI agent books an activity, it has access to whatever is in the system and nothing more. If the system does not contain verified credential data — if the ski school's instructor certifications are in a PDF filed in a compliance database that the booking system cannot query — the AI agent has no basis for evaluating whether the supplier is legitimate.

The AI travel era requires that supplier trust be machine-readable, real-time, and automatically verified at the moment of booking. Manual compliance processes, however well-designed, cannot meet that requirement.

two credential categories, one verification layer

The Activity Travel Protocol introduces a structured, machine-readable credential model as a core part of its Layer 1 (Identity and Trust) architecture. Every party in a protocol-compliant booking — traveller, operator, supplier, AI agent — holds credentials that are registered in the Party Registry and verified by the Security Kernel before any state transition is allowed.

The protocol defines two primary credential categories.

Traveller credentials establish who the traveller is and what they are entitled to do. They cover identity (passport/identity document), entry entitlement (visa and immigration status), age verification (for age-restricted activities), travel insurance (coverage type and validity period), medical and fitness status (relevant to safety-critical activities), and minor status (triggering additional Duty of Care obligations). For activities that involve physical risk — ski instruction, diving, high-altitude hiking — the protocol supports structured wellness status declarations that feed into the Pre-Activity Collection workflow.

Operator and supplier credentials establish who the business is and that it is authorised to offer the activity it is offering. They cover business registration (legal entity verification), sector licence (operating authority in the relevant jurisdiction), activity-specific certification (instructor qualifications, guide certifications, safety compliance), public liability insurance, financial protection (bonding or insurance against insolvency), and data protection registration (GDPR, APPI, or equivalent).

Both categories share a common property: they have an expiry date. The Party Registry tracks credential validity and triggers renewal alerts before expiry. A supplier whose public liability insurance lapses cannot participate in new bookings until the credential is renewed and re-verified. The Security Kernel enforces this at the state transition level — not as a reporting finding that someone must act on, but as a hard block on booking creation.

Verification at state transition, not at onboarding. The critical architectural difference from current practice is timing. In the current model, credentials are verified at supplier onboarding — once, when the relationship is established — and then assumed to be current until someone notices they are not. In the Activity Travel Protocol, the Security Kernel verifies credential validity at every consequential state transition. A booking cannot be confirmed with a supplier whose licence has expired. This is not a business rule implemented in application code; it is a protocol enforcement mechanism.

One submission, network-wide recognition. When a ski school submits its credentials to the Party Registry, those credentials are accessible to every ATP-compatible booking system. An OTA building on the protocol does not conduct its own compliance review — it queries the Party Registry, which returns the verified credential status. The ski school submits its documentation once. Every platform that uses the protocol gets the benefit.

what this changes for every party in the booking

For the OTA, supplier onboarding becomes a credential submission process, not a compliance audit. The manual compliance team does not disappear — someone still needs to verify that submitted credentials are genuine — but the ongoing monitoring, the calendar reminders, the mid-season gap risk, the per-platform duplication: these are replaced by a single Party Registry record with automated expiry tracking.

For the supplier, the compliance burden shifts from per-platform to once. A ski school that holds verified credentials in the Party Registry can participate in every ATP-compatible marketplace without resubmitting documentation for each one. The long tail of compliance work — maintaining up-to-date documentation across ten different OTA portals — is replaced by maintaining one Party Registry record.

For the insurer, the Party Registry is an evidence base. When a claim is filed, the insurer can verify that the supplier held valid credentials at the time of the booking, that the traveller's insurance coverage was active, and that the booking proceeded through the defined state machine. The immutable event log records every state transition and every credential verification event.

For the traveller, verified credentials are not something they interact with directly. They are the background guarantee that every party in their booking — the hotel, the ski school, the transfer operator — has been verified as a legitimate, licensed, insured business before the booking was confirmed. Not six months ago when someone last checked a PDF. At the moment of booking.