Pass vs Ticket
Pass vs. Ticket it was flagged that
- Pass is multi-use in that it can be used for:
- A prescribed number of times for events (including multiple times for the same event)
- Across a package of events or attractions (e.g., can go to 4 of 10 different events/attractions)
- Ticket is single use
- For a given attraction for a range of dates
- For a given date/time for a given seat or as general admission to an event
To be understood. Is the treatment of a multi-use Pass different from a ToIP perspective and/or any business requirement/operational issues?
Disbursing Passes
Issues:
- How can Bob re-assign the individual passes in his block of passes in a manner that is:
- Consistent with the terms and conditions as set out by the Attraction Pass Issuer
- Such that each pass is bound to the pass holder
Narrative
Bob wishes to transfer passes too
- His partner
- Son
- Daughter
- Friend 1
- Who duplicates the pass (unauthorized) to Friend 2
Assumptions on Pass/Ticket binding to a Holder
- For a Holder to receive one or more passes, they must present a DID that they control (e.g., keys), which the vendor binds to the pass(es).
- For transfer (give or resell) the vendor, on completion of the transfer removes the original holder DID binding and re-issues the pass/ticket biding the receiving holder’s DID.
Proposals
Pass holders can delegate/transfer/resell directly
It was proposed initially that the Attraction Pass Vendor delegates to Bob ability to transfer or re-sell to another person.
The following are possible terms and conditions:
- Permission by vendor to sell, transfer to another valid customer (e.g., no bots)
- This is extended to any eventual holder of a pass such that they can also transfer
- Attraction-specific terms and conditions (does the recipient have to be over 18, or substitute scuba diver with credentials)
- Requires Verifier verification of VCs (e.g., licensed driver, scuba-diver)
- Could include the signing/witnessing of Waivers
This potentially could allow device to device pass transfer/resale
There are several issues here:
- The Attraction Pass Seller and other ecosystem components will not have control of the process as Bob (or his delegates) initiates the transfer process.
- Requires that consumer wallets can execute on the verification of satisfying terms and conditions.
Pass holders must delegate to the Attraction Pass Vendor (or agent) to transfer or resell
This proposal allows any pass holder to transfer one or more passes to someone else but through a re-assignment/re-sale workflow controlled by the Attraction Pass Vendor and/or other ecosystem components/agents/resellers.
Pros
- Provides control to the Attraction Pass ecosystem on the transfer and resale.
- This includes validation for valid pass recipients (e.g., a traveller or concertgoer, not a bot). Could also include a ticker reseller (including the original vendor).
- This resolves all but the most expert of forgeries of a ticket/pass (e.g., hacking the ecosystem)
Cons
- Requires access to the Attraction Pass ecosystem (locally or via the cloud). Cannot do device-to-device transfer
For multi-use passes
- Holder can go to 4 of 10 attractions, including the same attraction additional times, each counting as a pass-use.
- Holder selects which attractions to attend by pre-selecting (or changing) via the cloud (via the ecosystem)
OR
Holder selects an attraction by presenting the pass at an attraction (redeem the ticket)
Note: neither of these approaches prevents out-of-band transfers as outlined in the Nov 7 minutes “Selling an Attraction Pass via a Side Deal. However, this is not an SSI/technical problem.
Redeeming Tickets
This poses several issues:
- How does the ticket holder know they are dealing with a valid Pass Verifier (PV)?
- Are there unknown issues with the PV verifying the holder’s DID (additional verification required)
- Scenarios – for redemption
- PV and/or Pass Holder is online to cloud, online to the local venue (local WIFI), has device/device communications
- Also need to consider a combination of PV and Pass Holder connectivity status/capability at the time of pass redemption.
- Dealing with multiple entrances to a venue
- Dealing with double use where ecosystem connectivity is compromised. How much can be done device to device?
Assumptions:
- A pass (and its state/status) may reside on a Holder’s wallet but must also be available (synchronizeable) to the ecosystem components at all times if both parties are online, automatically re-syncing when parties are back online.
- Example: Both Bob’s Partner and the Pass Vendor need to have up-to-date information on whether Bob’s Partner’s pass has been redeemed or transferred
- At the time of redemption, the copy of the ticket/pass accessible by the Pass Verifier is the authority (e.g., if there is a record of the pass having been redeemed in the pass visible to the Pass Ecosystem, then that takes precedence over the pass holder’s pass status.
- The PV is prioritized as determining the status of a pass.
- The PV must have a mechanism of capturing if a pass has been redeemed (worst case on their verification device)
- Duplicate use of Pass 4 (as shown in the diagram) should not be possible for a digital ticket (if ticket binding is only possible by the ecosystem)
- Business requirements suggest that the connectivity of, and control by, the Pass Verifier is of primary importance and the authority on whether a pass is valid
Scenarios
Control of ticket redemption of digital-only tickets is dependent on connectivity. The assumption is that connection type at a higher level is only possible if both the holder and verifier can use that connection type (and it’s available). Types, in order of connectivity types
- Cloud connection (cell, area WIFI, wired ethernet (verifier))
- Venue connectivity (venue WIFI, wired ethernet (verifier))
- Device to Device (cell, any form of WIFI down)
- No Holder/PV communication
Assuming that the PV is the important party in accepting a pass/ticket, there are differences in interaction and status of a pass (and which party has access to the most current status).
Pass redemption scenarios (Pass Holder - PH, Pass Verifier - PV)
- Cloud Connection
- PH and PV – PV checks with ecosystem copy of the PH’s pass as to whether redeemed
- Updates the PH’s copy if the status is different (e.g., still un-redeemed)
- Venue WIFI
- Same as for Cloud Connection, but via venue WIFI.
- Assumes that the venue has a local server with copies of the passes for the event and their current status
- The issue for updating the PH’s copy of the pass is dependent on whether they can (or are permitted) access to the Venue WIFI
- Device to Device (assuming compatible)
- Assumption: Pass Verifiers at the venue cannot connect to each other during the redemption period, so cannot exchange pass status with other PVs. So a PV can only know about tickets/passes that they redeemed. So this scenario only works for a single entrance/PV
- PV maintains a local copy of what passes they have redeemed. Can update the PH’s copy if supported.
- No Holder/PV communication
- Use QR, bar code or other visual presentation on the PH screen, scanned by the PV or a paper copy – no different than current non-connected device ticket/pass redemption.
- PV records ticket/pass redemption for a later update of the ecosystem and PH ticket/pass copies on reconnection to the cloud.
Where PV has cloud or venue WIFI connectivity but the PH does not.
- The PV will can read/update the ecosystem or venue copy of the holder’s pass, but may not be able to update the PH’s copy.
Requirements/Use Cases not yet covered
- Children must be accompanied by a parent: Where Bob is travelling with family, where the attraction requires VCs on the family relationships.
- VCs for attraction waiver requirements – examples include high-risk adventure attractions (scuba, parachuting) where VCs are required for participants (NAUI, PADI – scuba, FAI/PFFI – parachuting).
- Where would those VCs and waivers have to be presented?
- At least on pass purchase and at pass presentation (at attraction/checkin)?