Page Status: DRAFT
Priority: P2
This use case is based on the Issuance Use Cast text for mDL's supplied by Loffie Jordaan (Unlicensed)
Description (User Story)
The administrator in charge of an Issuing Authority should issue an mDL to conform to jurisdictional requirements.
Narrative
What happens during the use case.
Secondary Use Case (optional)
Actors
| Actor | Role in the use case |
|---|
| Alice |
|
| Bob |
|
| etcetera |
|
User Stories
| Element | Detail | Notes |
|---|
| As an Issuer | <description of user> |
|
| I want | <functionality> |
|
| so that | <benefit> |
|
| Acceptance Criteria |
|---|
| Given | <how things begin> |
|
| When | <action taken> |
|
| Then | <outcome of taking action> |
|
Prerequisites / Assumptions
- The Issuing Authority has the legislative authority to issue an mDL
Use Case Details
Privacy
Data Provided
Data Retained
Diagram
Steps
Primary Use Case
The anticipated normal sequence
| # | Step | Description |
|---|
| 1 | Verification | Ensure that the identity record to be provisioned into an mDL belongs
to the person requesting the provisioning (the mDL holder). |
| 2 | Provision Device | Ensure that an mDL is provisioned onto the device identified by the mDL
holder |
| 3 | Data Minimization | Ensure that the data provisioned supports privacy, specifically
including optional data elements that support data minimization |
| 4 | Qualify the mDL app | Ensure that provisioning only occurs into an app that provides the following functionality: - In case the request was received electronically, the mDL app must clearly convey what data was requested and whether the mDL verifier intends to retain the information. If the request is presented in summarized form in the user interface (e.g. “Identity and driving privilege data” as opposed to “First Name, Last Name, DOB, Driving privileges”), means must be available to give the mDL holder visibility of the details of such a summarized form, both before and during a transaction.
- The mDL app must provide the mDL holder full control over which data elements to share with the mDL verifier.
- ISO/IEC 18013-5 requires the portrait image to be shared if the portrait was requested and if any other data element is released (to enable the mDL verifier to tie the mDL information to the person presenting the information). The app must support a graceful and informed exit from the request if the holder opts not to share the portrait image when requested.
- If blanket sharing options are used, measures must be implemented to ensure that the mDL holder remains aware of what is being released when such an option is in effect.
- The mDL holder must at any time (i.e. during a transaction as well as outside a transaction) be able to view the mDL data, including technical data such as the signed, validFrom, validUntil, and expectedUpdate (if present) data elements from the mobile security object (MSO).
- The app must be capable of adequately protecting the mDL holder's data while the mDL is not in use by the mDL holder.
- The app must be capable of maintaining a log of all mDL activity.
|
| 5 | App Deletion | Ensure that an mDL holder is provided with the means to delete the mDL holder's mDL from the mDL holder's device. Such means: - Must delete all mDL information, log information, and any metadata (e.g. settings) that could impart information about the deleted mDL or its use.
- Must not require approval by the Issuing Authority.
- Must be an option available to an mDL holder on the mDL device.
- Should be available to an mDL holder via a request to the Issuing Authority (see below).
|
Secondary Use Case(s)
Alternate or variant sequences
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
Resources and Links
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date