Digital Travel Credentials

From IDESG Wiki
Jump to navigation Jump to search

Full Title

Digital Travel Credentials with a focus on Health Credential Use Case.

Context

To provide reasonably high assurance that a traveler has the Health and other Credentials needed to travel.

  • This effort is essentially a proposal to replace the Yellow Card or vaccine passports with Digital Travel Credentials.
  • See te wiki page
  • The working assumption is that the user would put certificates on their own phone at their own discretion.
  • The use cases are not dependent on a nation-wide repository, but can work with any regional or even laboratory certified clinical electronic health record (EHR) repository.

Goal

To allow digital proof of a traveler's compliance with requirements for travel that are collected from among many Credential Service Providers. For example: acceptable proofs might include:

  1. Negative test for a variety of health conditions, like COVID-19.
  2. A current certificate of vaccination of a particular disease which often depends on the area to which, or from which, a traveler visits.

Actors

  1. Traveler with a portable computing device called hereinafter a smartphone without prejudice to other devices that may meet the criteria.
  2. Electronic Health Record (EHR) holds the actual health event information and is prevented from blocking patient access to the information.
  3. Credential Service Provider can generate a health travel credential from Patient Health Information (PHI) from an EHR.
  4. Verifier of health credential (also can validate binding to Traveler)
  5. Access Agent that receives the verifier presentation and allows access of the Traveler.
  6. Suppler of travel accommodation.
  7. Internationally recognized Travel Trust Authority with an internet accessible registry.

Note that many of the actors are roles that could be performed by the same entity, for example in some jurisdictions 2 and 3 could come from the same service. Health records may be in regional centers, hospitals, labs or any HIPAA covered entity that has been certified. It is expected that some of these entities have also chose to be a Credential Service Provider for Digital Travel Credentials.

Preconditions

  • The Traveler has a smartphone, that can create a verifiable Presentation of the health information.
  • The Traveler has acquired a persistent digital identifier which is linked to a public key pair.
  • The Traveler has loaded a health credential into the smartphone.
  • The Traveler's smartphone or the access agent and trusted authority has a binding to a proof of presence method.
  • The current (untested) assumption is that consent to release credentials is contained in some phone feature. These are two possibilities:
  1. The credential is tied to the user wallet in such a way that a user gesture (like a finger scan) is required before release.
  2. The credential is transmitted over NFC which has a short range (see Smartphone wireless.)

Digital Identifiers can be issued as Medical Record Locators, National Health IDs or as Decentralized Identifiers (dids and did-documents).

Scenarios

Primary Scenario:

  1. Traveler has a ticket to ride from a supplier they have not previously used.
  2. Traveler is informed of the requirement for a Health Travel Credential.
  3. Traveler acquires Credential from a health care provider, for example a lab, which populates a record in an EHR.
  4. An approved Credential Service Provider accepts the record from the EHR and creates a Health Credential meeting the criteria of the Trust Registry.
  5. Access Agent asks traveler for a verified claim of Health with a nonce.
  6. Traveler smartphone sends verifiable Presentation of the Health credential they acquired from verifier.
  7. Access Agent asks verifier for proof. (This would be by redirect to verifier through traveler browser)
  8. Verifier supplies validated claim (or statement of non-revocation) bound to nonce by redirect to Supplier, if this VC is bound to the traveler’s session with supplier, it can have a lifetime of the duration of bound session.

Alternative Paths (eg a hydroplane going from Seattle to Victoria):

  1. Traveler has a ticket to ride.
  2. Supplier asks traveler for a verified claim of Health with a nonce.
  3. Consumer asks verifier directly for proof with nonce from Supplier.
  4. Verifier asks consumer to enter token for proof of presence.
  5. Verifier sends validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
  6. Consumer sends verified claim to supplier that can let them board immediately.

Worst Case Scenario.

  1. Family traveling together, husband and wife have their own credentials on their own phones.
  2. Children credentials must be located on someone else's phone.
  3. The current path leads to one wallet per credential.
  4. If that cannot be accommodated one parent will be searching around on their phone for many additional credentials.
  5. Of the whole family, one credential is not accepted by the security agent and the whole family misses the flight.
  6. There is no agency at the airport that can rectify the problem.
  7. One mitigation for this scenario would be a self-check web site where the parents could check every credential before leaving home.

A different path using biometrics:

  1. Yoti, a London-based startup which wants to become the “world’s trusted identity platform”, is one of many attempts to provide such a service. Its system stores government id documents and biometrics. If a travel want to use self-check-in and needs to prove their health, they scan a qr code and take a selfie using Yoti’s app. The retailer can be sure of their age, but no one has seen their name or nationality. From the Financial Times.

Failed Paths:

  1. Traveler does not get verified claim for some reason.
  2. Verified claims fails validation at verifier.
  3. Verified claims are false.

Results

Accepted Risks:

  1. The Traveler's EHR is compromised and has incorrect information.
  2. The Traveler is not healthy and has used a friend's lab results to acquire a health credential bound to the Traveler's did.
  3. Session hijacking mitigated with HTTPS and session cookies.
  4. MitM attacks mitigated by hardware token bound to origin URL of verifier.
  5. Note that the late binding token could be bound to travel supplier as well as needed.
  6. The identity of the verifier/validator is discoverable by the travel supplier.
  7. User makes choices on which attributes are trusted for sharing with the travel supplier. (For example, the user could have both a vaccination credential as well as a positive lab result.)

Post Condition:

  1. If validation accepted, and traveler completes payment, the access to the travel conveyance is granted.
  2. Note that at the end of the process of validating the traveler's health, the state issued conditions for travel will determine which path to use. The penalty for the travel supplier failing to follow correct verification procedures could result in civil penalties, including loss of use of travel trust registry.

Examples:

  1. Late binding token - FIDO U2F token, TEE TPM VSC, etc.
  2. Client-side code: JavaScript in a browser, native app, etc.
  3. Biometric matching is done in person by the Agent.
  4. Biometric matching is done by the smartphone which can unlock access directly.
  5. Access to efficient health services for tourists - an evaluation of the economic benefits shows other places where digital travel creds can be helpful.

Dependencies:

  1. Web Sites must be trusted before any user information is released.
  2. Trust federations can be used to help users make informed decisions.
  3. User consent and trust must begin with no traveler information transferred.
  4. Standards exist to collect needed attributes where-ever they may be.

Problems:

  1. Oppressive governmental or other agencies may track the traveler.
  2. The people's right to travel when and where they wish is abridged.
  3. It could back-fire in preventing sick people from traveling to a place where they can be cured.
  4. A traveler is blocked from legitimate travel because of bureaucratic or technical malfunctions.
  5. Most travel notifications systems are highly privacy invasive. Consider the IATA system:

    IATA Timatic is used by airlines and travel agents to verify passenger travel document requirements for their destination and any transit points. Airlines use various Timatic solutions to ensure their customers are compliant with border control rules and regulations. Timatic delivers personalized information based on the passenger's destination, transit points, nationality, travel document, residence country etc.

  6. The promise and perils of vaccine passports from the Economist 2021-01-26 - They are divisive, politically tricky and probably inevitable

Open Questions

The questions that are known so far are:

  1. What rules will be applied to create a COVID or vax card from the various lab reports. Current thinking is a policy framework that can be filled is as governmental rules are changed to adapt to the progress against COVID.
  2. Who will apply the rules to the lab results and create the card. This may not need to be solved immediately.
  3. What events should create updates to the card. Changes could be created by changes in scientific knowledge or governmental policy.
  4. How would updates be propagated to the card. Perhaps the card needs a very short lifetime, like 24 hours before travel commences.
  • for SSI geeks, the various lab reports can be viewed as verifiable credentials.
  • the vax card can be viewed as a verifiable presentation.

Workflow Diagram

TK

References

Retrieved from "https://wiki.idesg.org/index.php?title=Digital_Travel_Credentials&oldid=16002"