Meeting Date

23 Jan 2023 The DMRWG meets bi-weekly on Tuesdays at 12:00-13:00 PT / 16:00-17:00 UTC. Check the ToIP Calendar for meeting dates.

Zoom Recording & supporting material

Recording
Transcript
Raw Meeting Notes

Attendees

Main Goal of this Meeting

Discuss Layered Schemes as to their usefulness for complex, international data capture of a personal profile for Travelers (Travel Profile TF, spin-off of the DIF Hospitality & Travel SIG), which is a comprehensive example of real-world consumer-based PII/Sensitive data.

Given that Layered Schemas (Cloud Privacy Labs, Human Colossus) have been in development for two plus years, what is the experience with (PII/Sensitive) data exchange, internationalization, selective disclosure, interoperability, extendability and other topics

Agenda Items and Notes (including all relevant links)

Time

Agenda Item

Lead

Notes

5 min

Start recording
Welcome & antitrust notice
Introduction of new members
Agenda review

Chairs

Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
New Members:

55 mins

Discussion

All

The Traveler Profile project is designed to provide a common traveler profile model created with/by any person for them to control information about them and their travel "experiences" requirements and preferences needed by the Hospitality, Travel and Attractions industry.

Much of the profile is personal data schema (or collection of schemas) that is considered "PII" or "sensitive" data that, to be adopted by the industry, will need to fulfill a large number of requirements, including:

It is a presentation and data exchange format, to be independent of data storage structure and technology
Supports data privacy, including selective disclosure of schema metadata and actual data (values)
Internationalize-able (locale and language) and interoperable in terms of units, formats and other jurisdiction-differing data aspects
Ensure semantic interoperability (e.g., the meaning of data is the same regardless of structure or formatting)
Tailorable for different national and other jurisdictions
Extendable and versionable for structure and data values

As noted, there are two organizations who have developed solutions for similar requirements in the last 2 to 3 years using a "layered schemas" approach where a base schema (records and attribute definitions for data type, label, units, etc.) is extended by adding additional overlays on the based schema to provide additional metadata, including allowing, for example, changing the presentation language, but swapping in a new locale/language overlay.

Feedback, primarily from Burak Serdar who has been working in the US Health data field.

Selective disclosure is 80% on individual or collections of related attributes and is relatively straightforward. The remaining 20% (a combination of one or more record types and their attributes and while the layered-schema approach provides the metadata, performing and presenting these compound selective disclosure use cases requires external programming logic, which layered schemas alone (e.g., scripts, etc. in overlays related to records and attributes) cannot handle.

What to disclose or not disclose is context-dependent and whether an attribute or record is considered PII or sensitive data is insufficient. Context depends on the party requesting the information, the jurisdiction(s) of the traveler, the travel locations for a trip, the requestor (service provider), and the specific requirements of disclosure based on where in the travel/experience process. For example, planning and executing a trip has been proposed has several phases, from Discovery (initial information gathering), Shopping (looking for a price/feature fit), Booking (finalizing the trip), Registration (check-in), Service (trip in progress) and Post-Service (after the trip).

At the Discovery phase, the traveler can be essentially anonymous, but by the time they Register (check-in at the airport) they will need to fully disclose name, address, nationality, their passport, and tickets, and likely pass some biometrics test.

Data collection and custom views. While with simple data structures, data collection is possible with metadata in a layered schema, when data collected has interdependencies and choices by the user/traveler that impact what data is needed, then layered schemas (particularly for non-trivial information, including relationships of the travelers companions (e.g., family) needs assistance in collecting the data, ensuring interdependent fields are compatible and presenting the UI on the travelers device.

These notes will be expanded (as this opens up questions on the architecture, implementation and complications of a common Traveler Profile.

For more details, watch the recording; see the edited tanscript and the DMRWG Raw Meeting Notes and Transcript, which are listed at the top under Zoom recording.

Supporting Material:

Human Colossus Foundation

Overlay Capture Architecture (home page for supporting material)

Cloud Privacy Labs

Screenshots/Diagrams (numbered for reference in notes above)

Decisions

Sample Decision Item

Action Items

Sample Action Item

Browser not supported