Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Status: DRAFT

Information for organizations that issue mobile credentials, and by inference organizations that provide software or services to issuers to enable the issuer to issue mobile credentials.



Guidance for Issuers to enhance Holder privacy can be put in three groups:
1. Guidance related to the provisioning process.
2. Guidance related to app/wallet functionality.
3. Guidance related to mDL maintenance.


1. Guidance related to the provisioning process.

Provisioning is the process whereby a person's mDL is "put into" a mobile device.  Note that provisioning excludes the process under which an Issuer establishes an identity record for the Holder.
At a high level, provisioning comprises the following steps:

  • Holder requests Issuer to provision the Holder's mDL onto a device presented by the Holder.
  • Issuer identifies, in its own repository, the identity record describing the Holder.
  • Issuer confirms that the mobile device HW/OS/mDL container is "good enough".  "mDL container" as used here can include an app, a wallet, or other means by which mDL information, or the means to obtain mDL information (e.g. by way of server retrieval, as defined in ISO/IEC 18013-5), is stored on a mobile device.
  • Issuer places mDL "into" the mDL container.

The following privacy related considerations apply to the provisioning process:

  • The Holder must provide Issuer with sufficient information so the Issuer can identify the Holder's identity record in the Issuer's identity record repository.  The risk with using a too little information is that the identification process will yield an incorrect result; using too much information is undesirable from a privacy point of view.
  • Determining if a mobile device HW / OS / mDL container is "good enough" requires the Issuer to collect information about the configuration.  As in the case with Holder identification, the risk with collecting too little information is that the mDL can get provisioned to a device/OS/containiner that is not "good enough"; collecting too much information is undesirable from a Holder privacy point of view.
  • The Issuer must ensure that the data provisioned supports privacy, specifically including optional data elements that support data minimization.


2. Guidance related to app/wallet functionality.

An Issuer is in the position to control the properties of mDL apps.  To this end, an Issuer must provision an mDL only into a mDL container that provides the following functionality:

  • In case a mDL reader electronically transmits a request for mDL information, the mDL app must clearly convey to the Holder 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.
  • Ensure that an mDL holder is provided 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 a mDL holder on the mDL device.
    • Should be available to a mDL holder via a request to the Issuing Authority (see below).


3. Guidance related to mDL maintenance

One of the benefits of a mDL over physical credentials is the potential ability of an Issuer to keep the mDL information fresh.  This requires the mDL information to be updated from time to time.  Different technical solutions are available, each with different impacts on among others privacy and data freshness  (see e.g. Appendix A in the AAMVA mDL Implementation Guidelines).  An Issuer must carefully consider all impacts when selecting a technical solution.





Page Tasks

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