Solution Perspective

Who is this guidance for?

This guideline is for any party responsible for the deployment of a baggage information exchange solution. Specifically, these may be:

• IT Architects Developers. Individuals who need to design build and test a solution.

• IT Service Providers. Individuals who need to service manage a solution.

• IT Service Owners. Individuals who need to manage an IT service provider.

What does this guideline provide guidance on?

This guidance provides conventions for the configuration of protocols so on a worldwide basis airlines and partners in exchange of baggage information understand how to setup communication for the services defined by the BIX Working Group.

When should this guideline by applied?

This guidance should be reviewed at the design, implementation and service provision stages of an airline broker node.

Concepts for solution

In Baggage Logistics we recognize exchange of messages between Airline and its Handlers, between peering Airlines, and from Airline to Authorities.

Conceptually Baggage aligns with Modern Airline Retailing:

“The main principle is to split the source of content and the consumption of this content. The source sits in the airline eco-system, and the consumption is done by interfaces and/ or devices accessing these different airline systems, then triggering any update back to the airline systems”².

The source, the single source of truth for a bag (or baggage containing cart or ULD) is with the custodian Airline.

Message exchange is always from or towards the custodian Airline.

From the source there is an outbound connection (typically for instructions and notifications), and there is an inbound connection (typically for reports).

It is up to the custodian Airline to decide how reports reflect in updates to the source of truth.

Connections are established on request of the party that consumes baggage information and may post its findings.

The communication paradigm could be described as “connect directly to the source of the information”.

Solution Architecture

The architecture describes logical components, interfaces and communication concepts for the RP1755 standard. Regarding the already existing baggage system architecture and implementation rules at an airline or airport, the following mentioned terms or components will not be implemented in a specific environment, but functional implemented in other components.

The solution contains two parts, an information provider (single source of truth) and an information consumer (client to consume information and post findings).

The information provider -custodian Airline- exposes end points (a broker or an API gateway) where the information consumer can subscribe or publish (get or post) information on relevant baggage items

The protocol between end points and client acknowledges delivery of content, either through acknowledgement at level of protocol, or through a synchronous mechanism.

In case of asynchronous protocol, the protocol shall enforce delivery of content in correct sequence. In case of a synchronous protocol, a solution shall be available to prevent excessive polling.

Messages in transport shall be encrypted.

As an option, messages in transport may be signed to be tamper-proof.

For asynchronous messaging the broker and client shall exchange through a channel as per AsyncAPI terminology.

At time of writing the community lacks experience to express guidance on channel naming conventions other then

• Keep inbound and outbound channel between custodian and client distinct

• Keep channels distinct between two clients to respect confidentiality

• Consider to partition message exchange in distinct channels per airport

Architecture Components for asynchronous exchange scenario

The logical components are identified with help of AsyncAPI terminology

Baggage Producer and Consumer

The producer and the consumer interface to baggage systems of Airline and Handlers and provide capability to connect to the server.

Baggage Broker

The server exposes the end points where the conversation is channeled. This is where the “single source of truth” manifests itself. The server is controlled by the custodian Airline. In asynchronous communication the server is typically referred to as the broker.

Baggage System

The baggage system means the already existing baggage system at airlines or handlers where the baggage logic (including the RP1745 baggage communication) is implemented and baggage information is persisted.

These baggage systems must be extended to be able to deal with the RP1755 messages and mechanisms. As the airlines and handlers has different systems running, details on how to implement RP1755 are not covered by this document.

The solution perspective only shows how to communicate from an existing baggage system with the partners for RP1755 messages.

Note that a Baggage System can be either producer or consumer depending on the Role and Gesture in conversation

The airline baggage messaging node shall contain both a broker, a publishing message client and a consuming message client, all three front-ending the baggage system of the airline.

The handler baggage messaging node contains only a consuming and a publishing message client.

Via the baggage messaging nodes, the airline/airline and airline/handler communication for RP1755 messages is established.

Logical components of the baggage broker node are the Broker, the Baggage Message Consumer and the Baggage Message Producer.

Open

Figure 18 – Logical Components of Baggage Broker Node

Architecture

Open

Architecture Components for synchronous exchange scenario

Placeholder for future work

Implementation practices

End point discovery

The custodian airline exposes endpoints for channel communication with handlers and partners.

• Airlines may expose endpoints through their API platforms (e.g., developer.airline.com) and/or via IATA API Hub (https://api.developer.iata.org/hub/).

• IATA Baggage Community System (BCS) is a Directory Service is a potential mechanism for endpoint discovery for partner airlines who have subscribed to these services, but its exact implementation is expected to be live in the near future.

Cyber security

Access control

• A flexible access control mechanism should be adopted, but no single industry-standard approach is prescribed at the time of writing.

• Implementers may refer to:

  • Each partner (airline, airport, or ground handler) must authenticate before exchanging baggage messages. IATA Verifier Implementation Guide from the Identity Management Working Group for authentication and authorization models.

    • Leveraging the future IATA Baggage Community System (BCS) To exchange baggage message securely, each partner is authenticated after having an account in BCS, and then each partner (airline, airport or ground handling agent - GHA) create a profile in BCS portal. The participant can then request profile connection and if accepted, the participant can view assigned message exchange channels and view message conversion configuration setup by the channel.

Transport encryption

• Implementers should assume that TLS-based encryption will be required for securing MBM XML (RP1755) messages. Transport Layer Security (TLS) 1.2+ is recommended as a minimum standard for securing message transport.

  • Implementers should regularly review IATA and ICAO cybersecurity recommendations for any updates on encryption best practices.

• Leveraging the future IATA Baggage Community System (BCS) will support latest supported encryption protocol (TLS 1.3), and backward compatible with any supported version of this protocol (following IETF recommendations).

Message Signing

Baggage message schemas implement XML Signature (XMLDSig) based on W3C standards. Implementers should consider public key-based mechanisms for message integrity, aligned with future IATA security standards. Implementers are advised to consider IATA Digital Identity frameworks for signature verification and public key management.

Communication Protocol Guidelines

Overview

In computing, a communication protocol refers to the set of rules that computers use to communicate with each other. The protocol defines the signals that the computers will give each other, and other details such as how communication begins and/or ends, reliability, security and other non-functional communication requirements.

The following table lists messaging protocols that are often leveraged

Notes:

1. ISO/IEC Standards: Only MQTT and AMQP are ratified by ISO/IEC.

2. Community-Driven Protocols: Kafka is developed and standardized by its community rather than formal standards organizations.

3. TLS 1.2+ Support: All protocols mentioned support secure communication with TLS 1.2 or higher.

4. Protocol Choice: The choice depends on use case specifics like low latency (e.g., AMQP) or high throughput (e.g., Kafka).

5. Cloud Integrations: Managed services simplify deployment and scale.

6. Self-Hosting: Open-source and enterprise-grade options exist for organizations seeking full control.

About MQ-IPT:

• Purpose: MQ-IPT is a lightweight gateway that enables IBM MQ traffic to traverse firewalls securely over the internet.

• Key Features: Acts as a reverse proxy for MQ messages, supports TLS 1.2+ for encryption, and is ideal for scenarios requiring secure message transmission between remote MQ installations.

• Standards: MQ-IPT is proprietary to IBM and not governed by formal ISO/IETF standards.

Communication End Point Conventions

This chapter is based on AsyncAPI (https://www.asyncapi.com/en) as per IATA OpenAPI Working Group recommendations.

• Airline publishes Async API document to advertise how it makes baggage content available and how it expects to have results being sent back.

• Typical contents

  • Server (uri to the broker + port to the messaging protocol+ path to the service)

  • Channel (queue/topic or similar)

  • Operation (business name + schema reference + send or receive inclination)

• Either as part of AsyncAPI or as complementary OpenAPI document

  • Access endpoint (for authentication and access token)

Construction of channel name/address may follow suggestions on queue and topic conventions as per below

An implementing party can copy/mirror fragments from Airline AsyncAPI document into its own specification to establish communication between Airline and party.

The following guidance provides general conventions for the configuration of internet protocol (IP) for publicly facing end points. It is assumed that a single high availability, load balanced end-point is available per node.

End-Point Name Configuration

In managing the baggage exchange we want to distinguish

• Name and version of the service (name, major, minor)

• development life cycle for the service (prod, test, dev)

• channel for exchange between two parties

According to AsyncAPI a fully qualified channel address consists of

• Host and port

• Path

• Local channel address

The Host should be identified by a public Domain Name Address. There is no convention for this name.

It is recommended to include life cycle and high level service name in the Domain Name Address

The Port derives by convention from chosen messaging protocol.

The Path distinguishes between services at the host. It is recommended to include service name and major.minor version in the path

The local channel address is equivalent to “topic” in publish/subscribe pattern. This is where the custodian airline meets its handler or peer. The custodian is already identified in host. Hence the channel shall identify the handler or peer and it is recommended to further separate between outbound and inbound messages, and to separate between airports. Implementing parties may want to separate up to message type as relevant between two parties

End-Point Maintenance

AsyncAPI document fragments may be routinely downloaded and updated from source by connecting parties. It is recommended that this occurs on application start-up and a regular basis.

¹

² See Delivering with orders report at https://www.iata.org/en/programs/airline-distribution/retailing/consortium/#tab-2

^I