The one party we hadn’t
yet made real

Four arcs. Two years. One question answered at every layer: what does it mean for a machine to participate in a travel booking with the same trust, accountability, and authority that a human professional brings to it?

Arc 1 established identity and trust for operators and suppliers — the cryptographic foundations that let two parties who have never met transact with confidence. Arc 2 gave suppliers a machine-readable voice: here is what I offer, here is how it works, here is what I need to know about your guest. Arc 3 made the booking itself a live entity — not a database record that gets updated, but a process that runs, that fires events, that carries the guest from inquiry to completion and handles every disruption along the way. Arc 4 turned the protocol into software that developers can implement.

In every one of those arcs, the traveller appears. They’re there as a name, an email address, a phone number — the person the whole system is for. But they are not, in the current specification, a party. They don’t have a Party Record. They don’t authenticate. They haven’t explicitly authorised the AI agent that coordinates their journey on their behalf. They are, in protocol terms, a data field inside a Booking Object.

That was always the plan. And it was always the right one.

Why operators come first

The traveller’s identity, in the Activity Travel Protocol, federates through the operator’s identity — just as a passenger’s identity in an airline system runs through the airline’s verified infrastructure. The trust anchors have to exist before you can federate through them. This is not a deferral. It is the architecturally correct order.

Every significant open protocol has built identity in layers. OAuth 2.0 shipped in 2012 without OpenID Connect — consumer identity came as a deliberate second layer in 2014. The airline industry’s NDC standard launched in 2012 with supplier and distribution schemas; traveller identity and personalisation arrived in NDC 21.3 in 2021. OpenTravel Alliance defined supplier schemas for years before addressing travellers. These weren’t gaps. They were stages.

The Activity Travel Protocol Party Registry v0.3 adds the Traveller Layer. The traveller becomes a Party.

What it means to be a Party

In the Activity Travel Protocol, being a Party means three things: you have an authenticated identity, you can participate in protocol operations with that identity, and your participation is recorded in an immutable event log.

Until now, all three of those were true of operators, suppliers, travel agencies, and AI agents. From Party Registry v0.3, they are true of travellers too.

The Traveller Layer is not a consumer app feature. It is a protocol change. Every subsequent implementation — every mobile app, every cross-operator journey interface, every AI agent that a traveller instructs — is built on what is specified here.

What Party Registry v0.3 defines

• TRAVELLER
  party type A simplified Party Record designed for individuals, not organisations. No company registration, no mTLS certificate required. The authentication anchor is a verified email address or phone number. Identity is progressively enriched over time — a traveller starts with a phone number and can add a passport number when a booking requires it.
• Consumer
  authentication Four flows, covering what travellers already have: social OIDC (Sign in with Google, Apple, LINE), email magic link, phone OTP, and passkey. Operators choose which to support; the protocol defines the standard for each. No new credentials to manage.
• Traveller Identity
  Token A signed, portable credential that lets a traveller’s identity created at one ATP operator be recognised by another — without centralising personal data anywhere. The token contains a verified contact hash, not the contact itself. Cross-operator discovery without a central registry.
• Traveller-issued
  AI Agent mandates A traveller can formally authorise an AI agent to act on their behalf — with a cryptographically scoped mandate, capped at authority Level 2, revocable at any time. The agent’s authority is bound to the traveller’s Booking Objects. The traveller is now the principal, not a beneficiary.
• Consent records Protocol-level consent grants for data processing, AI agent authorisation, and cross-operator sharing. Timestamped, revocable, and attached to the TRAVELLER Party Record. The mechanism that makes APPI, GDPR, and PDPA compliance assertable at scale — not just operationally workable for a single operator.

What it unlocks

The Traveller Layer is a specification change. But what it makes possible is a different kind of product.

The Traveller Layer also completes something that has been implicit in the protocol since Arc 1: the full duty-of-care chain. Every phase of the Booking Object state machine has an assigned duty-of-care holder — operator, supplier, or guest-directed. When a TRAVELLER Party Record exists, the TU-1 through TU-6 escalation chain is no longer outbound-only. The traveller can respond through an authenticated channel. The emergency contact notification in TU-4 goes to a person the traveller chose, not one the operator captured in a booking form.

The trust question agentic travel keeps asking

The dominant question in the travel industry’s current conversation about AI agents is not “can the agent book?” It is “who authorised the agent?” Every editorial piece, every operator concern, every regulator’s inquiry circles back to this.

The current answer — from most agentic travel products — is that the operator authorised the agent. The operator holds the booking relationship. The operator’s system issues the agent its authority. The traveller benefits from this, but they are not, in any formal sense, the principal.

The Activity Travel Protocol’s answer, from Party Registry v0.3, is different. The traveller can be the principal. They can issue a mandate. They can set the scope. They can revoke it. And every action the agent takes under that mandate is recorded in an event log that is admissible as evidence of what was and was not authorised.

The EU AI Act requires transparency about automated decision-making. Japan’s Cabinet Office AI guidelines require human oversight mechanisms. Singapore’s IMDA Agentic AI Framework requires accountability at every delegation step. The TRAVELLER Party Record, the traveller-issued mandate, and the consent records in Party Registry v0.3 are the mechanism that makes all three assertable — not by adding compliance overhead, but because the protocol was built this way from the start.

---

A working draft, an open process

Party Registry v0.3 is publishing today as a working draft at activitytravel.pro/working-drafts/. The specification is complete enough to build against. The reference implementation — the Azusa Journey at MyAuberge K.K. in Chino, Nagano — will implement Phase 2 of the Traveller Layer this year.

Four questions are still open and will be resolved in the next working session: the structure of the emergency contact record relative to data minimisation requirements; the model for minor traveller proxy (parent or guardian acting on behalf of a child); traveller-facing MCP tool exposure; and verified travel documents in the TRAVELLER Party Record.

If you are building against the Activity Travel Protocol, or thinking about it, the working draft is the right starting point. If you want to participate in the open questions, open an issue at the activity-travel-protocol/protocol-spec repository.