Issue a mobile credential - mDL

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

ActorRole in the use case
Alice
Bob
etcetera


User Stories

ElementDetailNotes
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

#StepDescription
1Verification

Ensure that the identity record to be provisioned into an mDL belongs
to the person requesting the provisioning (the mDL holder).

2Provision Device

Ensure that an mDL is provisioned onto the device identified by the mDL
holder

3Data Minimization

Ensure that the data provisioned supports privacy, specifically
including optional data elements that support data minimization

4Qualify 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.
5App 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

#StepDescription
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



Page Tasks

  • Type your task here, using "@" to assign to a user and "//" to select a due date