Common Use Standards

The CUSS Task Force is working on the development of the next CUSS Technical Specifications, version CUSS 2.0. Access the CUSS 2.x Fact Sheet

Why CUSS 2.0?

• Most of the technologies incorporated by CUSS 1.x have already reached their End of Life, will be deprecated within the next years, are already not maintained anymore or have changed the licensing model to an unfavorable one.

Expected benefits of CUSS 2.0

• CUSS 2.0 will make use of the latest Web Technologies like OpenAPI, Oauth2, HTML5, JSON, TLS > 1.2 and WebSocket technologies enabling Web Developers to implement CUSS applications.
• Compliancy with other standards such as Payment Card Industry Data Security Standard (PCI DSS), General Data Protection Regulation (GDPR), etc. The use of current technologies allows to comply with current payment, privacy and security standards and regulations.
• CUSS 2.0 follows the “Security by Design” principles and supports Secure Technologies.
• Integration of Handheld Devices enabling contactless requirements.
• Supports a range of portable electronic devices such as tablets and mobile phones.
• CUSS 2.0 will allow a better compatibility with the latest technologies and shorter release cycles resulting in implementation and maintenance cost savings.

Important timelines for CUSS 2.0

• Mid-2024 – Technical Specification Release
• 1 January 2026 – CUSS 1.x platforms are discontinued 

How to get involved in CUSS 2.0?

IATA Member airlines, airports and strategic partners are welcomed to participate in developing the standards. The IATA Strategic Partnership Program offers the Common Use area of involvement.

In June 2021, IATA published the updated Recommended Practice 1791d  - Payment Card Industry Data Security Standards (PCI DSS) and Strong Customer Authentication (SCA) Compliance - which was adopted at the Passenger Service Conference.

How does this impact Airlines when accepting payments on Common Use Equipment?

Since September 14, 2019, EU regulation requires that Strong Customer Authentication (SCA) be applied to all card sales including “face to face” transactions. In such situations, when card and cardholder are present at the point of sale, chip and PIN is the expected solution. This regulation applies equally to all sales, direct and indirect, including sales from any Common Use systems regardless if self-service or agent facing equipment is used.

Any Common Use Self Service (CUSS) kiosk and/or Common Use Passenger Processing Systems (CUPPS) / Common Use Terminal Equipment (CUTE) workstation equipped with legacy MSR cannot perform SCA requirements nor deliver PCI DSS compliance.

PCI DSS compliance regulations state that cardholder information must be encrypted whenever it is stored or transmitted. Encrypting files involve the conversion of information into an unintelligible form that can only be decrypted by the holder of a designated cryptographic key.

Legacy MSRs cannot encrypt transmission of cardholder data, thus putting the cardholder at risk of credit card fraud, identity theft and other types of theft associated with the use of payment card information. In addition, the culmination of the chip roll out will lead to the card industry decommissioning ultimately the magnetic stripe technology. As an example, Mastercard has announced that as of 2024, they will start issuing credit and debit cards without magnetic stripes in Europe.

The  latest version of RP1791d can be found in the Passenger Standards Conference Resolution Manual available on the IATA store.

Microsoft recently announced that the Internet Explorer 11 desktop application will be retired on 15 June 2022.

Internet Explorer desktop applications will be out of support as of 15 June 2022 and the Internet Explorer 11 desktop application will be disabled through a Windows 10 cumulative monthly update for certain versions of Windows 10. Legacy Internet Explorer-based websites and applications will continue to work within Microsoft Edge's built-in Internet Explorer mode.

Microsoft states that applications built for Internet Explorer 11, supported versions of Google Chrome and Microsoft Edge Legacy should work within Microsoft Edge Internet Explorer mode.

Airline members that are using Internet Explorer in their CUSS application should plan to adjust their application to the more modern Microsoft Edge browser or switch over to the Bring Your Own Browser (BYOB) function of CUSS.  A mitigation plan should be developed with your respective CUSS platform providers to end the dependency to Internet Explorer prior to its End of Life in order to keep your application safe and supported.

Read more about Internet Explorer 11 End of Life FAQ.

The BCBP group of experts updated Resolution 792 version 8, which has become effective on June 1, 2020.  

The list of changes to Resolution 792 - Version 8 is as follows:

• Gender Code - Field 15: Gender Code the gender code “X” which is defined as “Unspecified” and gender code “U” defined as “Undisclosed”.  

The list of changes to Resolution 792 - Version 7 which came into effect on June 1, 2018 is summarized below. Section 2.2.4 provides additional information and examples related to certain data elements contained in the standard for implementation purposes:

• Bar Code on Printed Boarding Pass: the default Bar Code presented on printed boarding pass is a 2-dimensional Bar Code in PDF417 standard containing a structure data message (SDM). On the request from the Airlines version 7 extend the standards to allow Aztec, Datamatrix or QR code formats on printed boarding pass those formats are currently used on Electronic (Mobile) Boarding Pass only.
• Field 23 (Baggage Tag License Plate Number (s)): last 3 digits have been changed to follow RESO 740/RP1745 where 001= 1 bag, 002= 2 bags, 007= 7 on version 6th of RESO 792, 000=1 bag.
• Field 6 (Field Size of variable size field): there was a change in the Implementation Guide where the previous version stated: Items 8 to 118, Plus Item 4, and now Size of data used within the subsequent conditional and airline individual fields (items 8 to 254, plus item 4) in ASCII-printed hexadecimal. If not used, enter "00."
• Field 10 (Field Size of following structured message - unique): there was a change in the Implementation Guide where the previous version stated: Items 15 to 23 the updated version: Size of data used within the subsequent fields (items 15 to 32), in ASCII-printed hexadecimal. If not used, enter "00." Should only count for the length of the conditional data identified as unique. In other words, it is the sum of the length of items 15, 12, 14, 22, 16, 21, 23, 31 and 32.

US company Adobe has announced the End of Life of the Flash Player. Adobe no longer supports Flash Player after December 31, 2020 and no new updates or security patches for this software will be published. The company also states that Flash-based content will be blocked from running in Adobe Flash Player after the EOL date. Meanwhile open standards such as HTML5, WebGL and WebAssembly fulfill the role of Adobe Flash.

As a consequence to the above announcement, application suppliers and providers cannot expect a newer Flash or Shockwave version than the latest one released by Adobe in 2020 and distributed on a CUSS platform. 

Application providers still using Adobe Flash as a technology in their applications must double check with CUSS platform providers on the latest Flash version available on the targeted CUSS platform and if this version still plays Flash based content.

As of 2021 the Common Use Self Service TSG will no longer list Adobe Flash and Shockwave plug-in’s as a required presentation technology in its CUSS specification(s).

The Common Use standards used for passenger processing will not be supported on systems using the Windows 7 operating system as of January 14, 2020.

Read the Common Use Windows 7 - End of Life document.

It is urgent that all parties migrate systems from Windows 7 to a current supported operating system, such as Windows 10 to maintain flight operations at airports, and to reduce risks and costs of security breaches.

The Common Use standards used for passenger processing will not be supported on systems using the Windows XP operating system. 

It is urgent that all parties migrate systems from Windows XP to a current supported operating system, such as Windows 10 to maintain flight operations at airports, and to reduce risks and costs of security breaches.

Airlines, airports and service providers need to be aware of the U.S. DOT final rule on kiosk accessibility that became effective on December 12, 2013.

The rule requires that:

• All airlines must ensure that all proprietary and common use kiosks installed on or after December 12, 2016 that they own, lease or control at U.S. and Canadian airports with 10,000 or more annual enplanements meet detailed accessibility design standards until a total of at least 25% of each type of the kiosk provided at each location in the airport meet these standards. At least 25% of kiosks in each location at a U.S. airport must be accessible by December 12, 2022 and by December 31, 2022 for Canadian airports.
• All airlines in addition to U.S./Canadian airports must ensure that accessible kiosks are visually and tactile identifiable and maintained in working condition
• All airlines must give priority access to accessible kiosks to passengers with disabilities
• All airlines must provide equivalent service to passengers who cannot use accessible kiosks that airlines own, lease or control due to disability

The U.S. DOT will be conducting onsite inspections to see that the rule has been enforced appropriately.

Beginning with IATA CUSS version 1.4, the standard and technical specifications provide the necessary framework to enable current accessibility standards. Airlines, airports and vendors should maintain an ongoing compliance plan to meet accessibility requirements and are strongly recommended to document all efforts.

For information, the rule also covers two other elements of airline website accessibility and wheelchair stowage that are not related to common use activities.

View the official information on the U.S. DOT rule.

View the Canadian Transport Association official information on Removing Communication Barriers for Travellers with Disabilities.

View the official Directive of the European Parliament and of the Council.

Although CUPPS already allows the use of mobile devices, Wi-Fi networks and even remote access for airlines to airport peripherals, the following new features are included in the CUPPS 1.04 specification:

• It is possible to use CUPPS with a baggage drop device that operates in a common use environment. The baggage drop device has the status of "Defined, Required" in the latest CUPPS 1.04 specification and can be implemented based on the IATA Technical Peripheral Specifications (ITPS) version 2019.
• A snapshot reader device is also defined and allows taking snapshot photos on a conveyor belt in the case of a baggage drop device or any other area as required. It can also return a picture from any full-page scanner used for passports or biometric devices.
• Self boarding gates are now "Defined, Required" in CUPPS instead of being just optional.
• An electronic payment device simply allows full bi-directional data exchange of any nature to facilitate future integration with a generic payment module.
• Simulated hardware can now be used to facilitate platform compliance for complex devices such as baggage drop and electronic payment.

While new features were added, part of the work concentrated on streamlining the existing specification. For example, a simpler way has been put in place for airlines to do host printing. Other devices such as beep and display devices were marked as obsolete as they are no longer used as separate devices. Certain hardware requirements were also modified to ease various cloud and virtualized deployments.

The whole passenger process has changed and continues to evolve. There is now an expectation on airports and airlines to provide passengers with multi-channel self-service and accessible capabilities (i.e. web, kiosk, mobile phone, auto check-in, self-tagging, self-bag drop, self-boarding, etc.). At the same time, there is a need to maintain legacy infrastructure to continue to provide full-service options for some passengers.

The Common Use Group had developed the following vision in order to have a more flexible infrastructure and improve the customer experience: “Common use will provide flexibility of choice to deploy services based on interfaces adhering to industry standards”

These interfaces will range from Web Services, Cloud computing and mobile devices through to standard desktop offerings.

Whether platforms are physical or virtual, there will be standard interfaces presented to the application so that the concept, first introduced by CUPPS and CUSS, of "certify on one platform, run on many" will remain as a core principle.

There is an increasing demand for guidance on what are the desirable components of a solution that would support the "multi-merchants/multi-acquirers" business model of common use positions at airports which are shared by several airlines.

A Business Requirement Document (pdf) was put together providing recommendations that airports and airlines should consider when drawing up their own business requirements. These business requirements do not recommend any technology or provider and only seek to establish the key components of an effective industry card payment for this specific environment.