Biometric Pre Check
Page Status: DRAFT
Priority: P2
Description (User Story)
The holder of a mobile credential with an embedded picture (or fingerprint or iris scan) is able to create a ticket (aka access token) that can be used to board a plane or access a ballpark with just a biometric check.
Narrative
At home, the holder of a mobile credential on their smartphone (or laptop) can purchase a ticket for travel or entry to a sports venue that is equipped with biometric scanning devices.
Secondary Use Case
- The user must present a health credential as a part of the access check.
- The user has an access token added to their smartphone that can be used as a backup if the biometric fails for some reason.
- Access tokens can be printed as QR codes for use if both the biometric scanner and the smartphone fail to provide access.
- The airline has a scanner at the gate to the airplane that verifies the holder will be allowed in the destination country.
Actors
| Actor | Role in the use case |
|---|---|
| Holder | Holds a mobile credential with a picture. Wants to take a trip or enter a sports venue. |
| PDP - Seller | Policy Determination Point (PDP) is the role. Seller is the entity that may take on other roles as well. Is a website that is accessed by the Holder and creates the ticket using one or more mobile credentials. |
| PEP - Verifier | Policy Enforcement Point is the role. Verifier is the entity. A biometric scanner verifies the person as the holder of the ticket (access token). |
| Policy Maker | Government or business that creates a policy that is used for access check. Some policies may be subject to fairly frequent updates. Many real-world use cases will need to accommodate policies from multiple governments and other organizations. |
| Issuers | of the various mobile credentials held in the user's wallet. For this example case, they are (1) Driver's license, (2) COVID Immunization, and (3) Credit Card |
User Stories
| Element | Detail | Notes |
|---|---|---|
| As a | human user with a smartphone containing several mobile credentials | |
| I want | to travel to a foreign country or enter a sports venue | |
| so that | I can check that I have the privileges needed to access my destination | |
| good UX | I will know at booking that I have creds needed, or how to acquire them | |
| better UX | I will check within 24 hours and get a confirmation that I WILL be allowed in | |
| best UX | I will understand that my bio template will be removed when access is completed. | |
| Acceptance Criteria | ||
| Given | Holder has (1) Driver's license, (2) Covid Immunization, and (3) Credit Card | |
| When | The trigger is the user's desire to travel to a foreign country or a sports venue | |
| Then | The credentials need to satisfy both the seller and the policymaker(s) | |
Prerequisites / Assumptions
- The user journey improves access speed and cost for both the holder and the access checker.
- There exists a policy language (like XACML) that will be used to create the check for both pre-check and access check.
Optional value-added features.
- The access pre-check performed by the user at the computing device will have a lifetime of several days. The policy check made at that time till continue to be valid even if the policy changes.
Use Case Details
Privacy
There are (in effect) two distinct access credentials created as a result of this process. One inside the seller's (or government's) system that can be used for the real-time access check. A second that can be held by the user's smartphone.
Data Provided
The seller needs to acquire a REAL ID for the holder which must include biometric data. This is highly sensitive and must not be shared. The verification device can send a real-time biometric scan but does not see the store biometric data.
| Access Token | The holder of the mobile credential may be given yet another credential with provides access to the venue. This is proof that can be used if the biometric check fails. In this case, the seller also takes on the role of the issuer of the access token. Access tokens from many use cases will require credentials from multiple sources in order to be verifiable. |
| Presentation | Most credentials will have more data that the holder wants to release. The wallet will need the ability to selectively disclose attributes into the presentation to the verifier. |
Data Retained
The seller may maintain the holder's legal name for as long as a relationship exists with the holder. The holder may terminate the relationship at any time. The seller will delete all references to the holder as soon as legally permitted.
The retention of biometric source data (like the user's image) is a difficult decision, but the holder must understand what happens to biometric data.
Diagram
The solid lines are digital presentations. The dotted lines are physical presentations, not all of which are required or even desired.
Steps
Primary Use Case
The anticipated normal sequence
| # | Step | Description |
|---|---|---|
| 1 | acquire creds | preconditions, the user may be told more creds are required and need to restart the process. |
| 2 | visit sellers web site | starts anonymous |
| 3 | Select destination | date, time, etc. |
| 4 | Asked for consent | The seller needs to communicate clearly to the holder |
| 5 | Presentment of creds | Seller accesses as many apps on the user's device as needed to acquire all needed data |
| 6 | Seller issues ticket (PDP) | To user wallet as well as to the verification endpoint(s) |
| 7 | Check-in (PDP) | may be optional. For example within 24 hours of arrival at PEP |
| 8 | Holder at scanner (PEP) | Biometric check with no other human required - user walks on through. two scanners for international travel, one at embarkation and one at debarkation. |
Secondary Use Case(s)
Alternate or variant sequences
| # | Step | Description |
|---|---|---|
| 1 | No smartphone | issuer provides ticket as a QR code - also useful as a backup to non-functional phone |
| 2 | No biometric scanner | The verifier can accept a phone, radio, or QR code and sees a picture of the holder on the screen. |
End State
When the user has completed all of the accesses permitted by the ticket. (For travel this could include a return trip.)
Success
The user is never held up waiting for a human to check the access ticket.
Real-world experience for access to board plane is a reduction of time by 50%
Failure
Verification fails - user needs to visit help desk - typically a real-world help desk.
References
Champions / Stakeholders
Tom Jones
Related Material
Resources and Links
Your Face Is, or Will Be, Your Boarding Pass New York Times 2021-12-07
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date