Pay & fulfill - fulfillment

[OlivierBigex]

@oven : food for thought about fulfillment.
Transmodel introduced several concepts (and could be improved):

• FULFILLMENT METHOD: The means by which the TRAVEL DOCUMENT is delivered to the TRANSPORT CUSTOMER, e.g. online, collection, etc.
• TRAVEL DOCUMENT: A particular physical evidence to be held by a passenger, (ticket, card, etc..) allowing the determination of the right to travel or to consume joint-services. May comprise just a token associated with an online account, or some form of representation of the access rights.
• TYPE OF TRAVEL DOCUMENT: A classification of TRAVEL DOCUMENTs expressing their general functionalities and local functional characteristics specific to the operator.

OSDM has (and could be improved):

• Fulfillment type : ETICKET, CIT PAPER, PASS_CHIP, PASS_REFERENCE
• Fulfillment media: type : RCT2, RCCST, UIC_PDF, PKPASS, RETAILER_APP, DISTRIBUTOR_APP, TICKETLESS, SMS, WALLET
• Document format: pdf, jpeg, text...

Corom tried a mapping which seems to me incorrect.

Other standards have their fulfillment concepts as well.

Anyway, the retailer shall know how the travel document will end in the traveler's hands (or not!) and what he shall do for that. Thus, the fulfillment BUC needs to distinguish:

• the kind of fulfillment
• the final form of a fulfillment
• the norm or layout used: CALYPSO, UIC PDF, RCT2...
• the storage location: in the document or in system

Of course, a single fulfillment shall have several media: I can have my train ticket on my phone (2D barcode) and in a printed pdf.

Examples:

• CHIP / ISO7810_CARD / CALYPSO_CARD / ON_SYSTEM = the ticket is stored on a chip, which is on a chip card, according to Calypso protocol and only a reference is stored (ABT).
• ETICKET / PAPER / UIC_PDF / ON_MEDIA = a classic stand-alone pdf ticket

==> What do you think ? how to be sure in the way the BUC is written that the retailer gets all informations about the fulfillment, covering all fulfillement methods ?

[oven]

One thing I worry about is that new ways of ticketing will appear immediately after our API is published. This means that it is difficult to create an exhaustive list of formats and delivery methods without having to revise that list quite often.

Maybe we could try to provide metadata about the different fulfillment options in a way that is (hopefully) future proof when it comes to new fulfillment options?

For instance, if a Distributor offers a PDF, it could be described as having content type application/pdf, it would have a URL, and it would be marked as an URL that you can pass on to the customer. The Distributor could also opt to download the PDF and send it to the Customer by email.

Another example could be that the ticket is available as a digital credential in accordance with eIDAS 2.0. Then it would have a URL with protocol openid-credential-offer://..., and it would be marked as an URL that you can pass on to the customer. That would then initiate a process where the Customer gets the ticket in their digital wallet.

If we go down this route, the physical media (paper, electronic file, etc) becomes less important, instead focusing on which URL to use, who can access that URL (Retailer or Customer or both), which kind of fulfillment this is, and other bits of information the Retailer needs to be able to present the options and pass on the ticket to the customer.

[OlivierBigex]

I totally agree. My concern is not to provide a full list of enums, but to be sure that OTI can describe all kind of fulfillment methods in order to let the retailer know how to behave and how to inform the customer.

[edwinvandenbelt]

Agree. And we can work out an 'implementation' here, maybe starting with only our common sense,

• Starting with how it can be inspected/validated/give access.
• What are the possible carriers (normal paper, special paper, mobile phone) - (in other words, what do you show when you want to show the proof)
• The technical specification (directly telling it is a barcode, a QR code or something else)
• The way it is supplied (image type (PNG, ...) , json, PDF, HTML, ... ) (IATA defined), and optionally the dimensions to take into account in an app
• maybe some additional stuff regarding printing (allowed to print at home, ...)

Do we need more? We could start a separate BUC for this.

[oven]

Some URLs start a flow with the Customer's device (like an URL to start adding a digital proof to your wallet), others are resources that can be downloaded and passed on to the user.

[edwinvandenbelt]

Agree. Starting there, I'd say that the first thing to 'model' is: where should it be stored (and fetched upon inspection)

• Storage:
  type: string
  enum: [personal wallet, online, download_to_mobile]

Secondly, the retailer must know how to interpret and show it (this includes binary base64!)

• MediaType:
  type: string
  description: >-
  IANA media type of the travel document content (e.g. "application/pdf", "image/jpeg").
  Used to determine how to process or display the document.

Thirdly, the standard might be required when displaying (e.g. to format the binary information provided):

• https://github.com/TransmodelEcosystem/EUDIT/blob/0aa18dd0ff069bf41b156a0dba9b7c80d4eccb28/deliverables/1%20search%20offers/Fulfillment.yaml (like QR Code)
  type: string
  description: The content standard of the offer.
  x-enum-values:
  - "ISO/IEC 18004" # QR Code
  - "ISO/IEC 24778" # Aztec Code
  - "ISO/IEC 15438" # PDF417
  - "ISO/IEC 16022" # Data Matrix
  - "ISO/IEC 15417" # Code 128
  - "ISO/IEC 16388" # Code 39
  - "ISO/IEC 15420" # EAN-13
  - "ISO/IEC 15417" # UPC-A
  - "ISO/IEC 15424" # MaxiCode
  - "ISO/IEC 7816-4" # NFC, MIFARE DESFire
  - "GATT" # Bluetooth Low Energy
  - "AXA Bike lock" # AXA Bike lock
  - "OTHER" # Other content standard

And of course, where to obtain the 'ticket'/'fulfilment':
type: string
format: URI

And, optionally, in case of a binary image (or an embeddable PDF/HTML), the width/height.