Digital Travel Credentials: Difference between revisions
Jump to navigation
Jump to search
Line 4: | Line 4: | ||
==Context== | ==Context== | ||
To provide reasonably high assurance that a traveller has the Health and other Credentials needed to travel. | To provide reasonably high assurance that a traveller has the Health and other Credentials needed to travel. | ||
* This effort is essentially an effort to replace the Yellow Card<ref>Christopher Elliott, ''What you need to know about vaccine passports'' Washington Post (2020-12-30) </ref> with [[Digital Travel Credentials]]. | |||
===Goal=== | ===Goal=== |
Revision as of 20:18, 24 January 2021
Full Title
Digital Travel Credentials with a focus on Health Credentail Use Case.
Context
To provide reasonably high assurance that a traveller has the Health and other Credentials needed to travel.
- This effort is essentially an effort to replace the Yellow Card<ref>Christopher Elliott, What you need to know about vaccine passports Washington Post (2020-12-30) </ref> with Digital Travel Credentials.
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 inlcude:
- negative test for a variety of health conditions, like COVID-19.
- a current certificate of vaccination of a particular disease which often depends on the area to which, or from which, a traveler visits.
Actors
- Traveler with a portable computing device called hereinafter a smartphone without prejudice to other devices that may meet the criteria.
- Electronic Health Record (EHR) holds thee actual health event information.
- Credential Service Provider can generate a health travel credential.
- Verifier of health credential (also can validate binding to Traveler)
- Access Agent the recieves the verifier prsentation and allows access of the Traveler.
- Internationally recognized Travel Trust Registry
Preconditions
- The Traveler has a smartphone, that can create a verifiable Presentation of the health information.
- The Traveler has acquired a persistent identifier which is linked to a public key pair, like a did and did document.
- The Traveler has loaded a health credential into the smartphone.
- The Traveler's smartphone or the trusted authority has a binding to a proof of presence method.
Scenarios
Primary Scenario:
- Traveler has a ticket to ride from a supplier they have not previously used.
- Traveler is informed of the requirement for a Health Travel Credential.
- Traveler acquires Credential from a health care provider, for example a lab, which creates a record in an EHR.
- An approved Credential Service Provider accepts the record from the EHR and creates a Health Credential meeting the criteria of the Trust Registry.
- Access Agent asks traveler for a verifed claim of Health with a nonce.
- Traveler smartphone sends verifiable Presentation of the Health credential they acquired from verifier.
- Access Agent asks verifier for proof. (This would be by redirect to verifier through traveler browser)
- 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:
- Traveler has a ticket to ride.
- Access Agent asks traveler for a verifed claim of Health with a nonce.
- Consumer asks verifier directly for proof with nonce from Supplier.
- Verifier asks consumer to enter token for proof of presence.
- Verifier send validated claim with nonce of supplier with short expiration time (10-20 mins - alternate life time of duration of session).
- Consumer sends verified claim to supplier.
- Monetization is by advertising from verifier to consumer.
A different path using biometrics:
- 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:
- Traveler does not get verified claim for some reason.
- Verified claims fails validation at verifier.
- Verified claims are false.
Results
Accepted Risks:
- The Traveller is not healthy and has uased a friend's token to enter into computer.
- Session hijacking mitigated with HTTPS and session cookies.
- MitM attacks mitigated by hardware token bound to origin URL of verifier.
- Note that the late binding token could be bound to travel supplier as well as needed.
- The identity of the verifier/validator is discoverable by the travel supplier.
- User makes choices on which attributes are trusted for sharing with the travel supplier.
Post Condition:
- If validation accepted, and traveler completes payment, the access to the travel conveyance.
- 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 trvel supplier follow correct verification proceedurs could result in civil penalties, including loss of use of travel trust registry.
Examples:
- Late binding token - FIDO U2F token, TEE TPM VSC, etc.
- Client side code - javascript in a browser, native app, etc.
Dependencies:
- Web Sites must be trusted before any user information is released.
- Trust federations can be used to help users make informed decisions.
- User consent and trust must begin with no traveler information transferred.
- Standards exist to collect needed attributes where-ever they may be.
Problems:
- Oppressive governmental or other agencies may track the traveller.
- The people's right to travel when and where they wish is abridged.
- It could back-fire in preventing sick people from travelling to a place where they can be cured.
- A traveller is blocked from legitimate travel because of burocratic or technical malfunctions.
Open Questions
The questions that are known so far are:
- what rules will be applied to create a COVID or vax card from the various lab reports
- who will apply the rules to the lab results and create the card.
- what events should create updates to the card
- how would updates be propagated to the card.
- 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
- Digital Travel Credentials (2019-06-25) TRIP 15th Symposium Louise Cole
- The wiki page Phone as Health Care Credential
- Two tech groups say they’ll merge efforts on digital vaccine cards