Status: DRAFT
Description (User Story)
The holder of a mobile credential with an embedded picture (or fingerprint or irus 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 which are 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.
Actors
Actor | Role in the use case |
---|---|
Holder | Holds a mobile credential with a picture. Wants to take a trip or enter a (e.g.) sports venue. |
Seller | Is a web site that is accessed by the Holder and creates the ticket using one or more mobile credential. |
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. The policy is subject to fairly frequent updates. |
Access Token | The holder of the mobile credential is given yet another credential with provides access to the venue. This proof that can be used if the biometric check fails. |
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 | |
Acceptance Criteria | ||
Given | <how things begin> | |
When | <action taken> | |
Then | <outcome of taking action> |
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.
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
Steps
Primary Use Case
The anticipated normal sequence
# | Step | Description |
---|---|---|
1 | ||
2 | ||
3 | ||
4 |
Secondary Use Case(s)
Alternate or variant sequences
# | Step | Description |
---|---|---|
1 | ||
2 | ||
3 | ||
4 |
Sequence Diagram
End State
Describe what measures or signifies the end of the case
Success
Markers or metrics that indicate success
Failure
Markers or metrics that indicate failure
References
Champion / Stakeholder
List of the people that created the use case
Related Material
Resources and Links