Information for Issuers

1.1

Requirement(Req)

Issuing Authority must be the legitimate issuer of a Digital ID credential.

The risk to user privacy of not including these requirement is user may be tricked into provisioning a credential by an issuer that does not protect their privacy, or by a bad actor looking to steel user information.

1.2

Req

Issuing Authority must be issuing a Digital ID credential covered by the scope of these Recommendations (e.g. driving license, national ID, passport).

1.3

Best Practice (BP)

Issuing authority may choose to include incremental fields in their data set (as defined in ISO 18013-5 standard), and that field may be usable in their own jurisdiction or country, but that information is at risk of not being interoperable.  

2.1.1

Req

Issuing authority’s authenticity is validated by a regional entity (e.g. AAMVA, AustRoads, eReg) or a “global entity.”  

2.1.2.

B.P.

Issuing authorities’ public keys may be shared directly within their own jurisdiction with peer government departments, though it is not required to do so and it may be easier to direct peer government departments to a public master list.

2.1.3

B.P.

Other than the exception in 2.1.2(a), Issuing authorities’ public keys are only published to the public key Master List of (a) their respective regional authority (e.g. AAMVA, AustRoads, eReg), or (b) a “global entity.” 

2.1.4

Req

In person, the only channel an issuing authority opens to release of the Digital ID is a digital channel with cryptographic verification, and the relying party may not rely upon viewing the Digital ID on the user’s device for verification. 

2.1.5

B.P.

Notifications to relying parties and distribution partners required when public key information is updated or changed.

2.1.6

B.P.

Sole technical service granted from issuing authority to Master List provider is to manage public keys on issuing authorities behalf.  

2.2.1

B.P.

List the channel(s) the Issuing Authority has selected for surfacing Digital ID (e.g. Government app, Vendor app, Digital Platform app).  

2.3.1

Req

Digital ID is stored on the device.

2.3.2

B.P.

Issuing authority app/ vendor solution are using (or excluding) the relevant features available on the devices and operating system.  

2.3.3

Req

User has control over the data that they are sharing, not the issuing authority, and the user determines what data from the Digital ID is shared

2.3.4

Req.

A user’s history of data released per transaction, and to which relying party, must be a capability of the Digital ID service with both options to delete this information and to retain this information. User should make a proactive choice on this configuration with no defaults.

2.3.5

B.P.

A user’s Digital ID data, transaction history, or any other metadata cannot be used or moved by the vendor without explicit authority from the user (or user’s authority given to the government).  

2.3.6

B.P.

Neither the device nor the Digital ID application will send Digital ID transaction information to any entity other than the Relying part(ies) as authorized by the user.  Unless required by law or official policy.    

2.3.7

B.P.

In an unattended use case, users cannot release data to other apps (or to Operating service/ device manufacturers) until such time as standards are in place, or best practices are emerging under a clear consensus (e.g. ISO 23220 WG4) and recommendations are established. 

2.3.8

B.P.

A user’s Digital ID data is the same as that on the system of record.  In addition, Device Public Key, Digital ID expiration date, and key attribute salts of each data field (all as defined in ISO 18013-5) are also stored in the issuing authority’s system of record. Controls are in place that keep them in synch.    

2.3.9

B.P.

Issuing authority will allow only allow device release of Digital ID data, and will not allow server retrieval (even if authorized by the user from the device), unless best practices emerge under a clear consensus that merit following this part of the ISO 18013-5 standard.

2.3.10

B.P.

To the extent that the device holds a Digital ID credential, transaction history or meta data, the user has the ability to selectively deprovision or delete each of these types of information from the device.   

2.3.11

Req

When user deletes the app that contains the Digital ID credential it automatically deprovisions the Digital ID credential from the device and all transaction history, meta data, and related settings from the device. (Require with conformance period.) 

2.3.12

B.P.

If transaction data is retained, the only entity that has access to the transaction history is the holder, who would have visual access to the Digital ID data, but no functionality for the user (or any other entity) to export the data off the device.  

2.3.13

B.P.

Issuing Authorities and government entities more broadly are responsible for their own identity credentials, and should not interfere with other credentials (eg Passport, national ID, driving license) that may coexist on the same device. 

2.3.14

B.P.

Issuing authority will comply with all local laws for issuing of Digital ID credentials.

2.4.1

B.P.

Digital ID (mDL, mPassport, mNational ID) to be updated in “real-time”, as system of record for the physical credential is updated. If the device is “offline” from the internet, the Digital ID credential is updated the next time the user connects to the internet.  

2.4.2

Req

If physical Identity credential is revoked for fraudulent reasons the Digital ID credential is revoked (such reasons are defined under Issuing Authority procedures).  

2.4.3

Req

If the physical Identity credential is stolen and the Issuing Authority invalidates the document discriminator from the SOR, the invalidated physical identity credential may not be used to provision a Digital ID credential again.  The Issuing Authority staff person needs to inquire whether the device was also stolen. If the device was not also stolen, then the Digital ID credential is not impacted.  

2.4.4

Req

If the device is stolen, the Digital ID credential is revoked even if the physical identity credential is not also stolen. The physical credential can be used to provision a new Digital ID to a new device.   

2.4.5

B.P.

If the physical Identity credential is reported as being lost (or subsequently replaced) the Digital ID credential is not impacted.   

2.4.6

S.P.

If a device containing a Digital ID credential is reported as “lost” by the user, the user may suspend the credential for a week or two. To reactivate the credential the user would need to lift the suspension. If the period of time expires without the user lifting the suspension, then the Digital ID credential is deprovisioned and the user will need to reprovision.  (May be device or OS dependent whether this is available for use by Issuing Authorities).

2.4.7

B.P.

If physical Identity credential is revoked for other reasons than fraud, stolen, or lost (e.g. a new credential is issued in another state) the Digital ID credential is deprovisioned.

2.4.8

B.P.

If a privilege is revoked (e.g. driving privilege), Digital ID credential may be used for the non-revoked privileges and as an identity credential. It is recommended that the Issuing Authority does not charge the user fee for changing the status of the Digital ID credential in the app.

2.4.9

B.P.

If credential expires (e.g. driving license privilege), Digital ID credential may be used as an identity credential and for other unexpired privileges for as long as permitted under issuing authority law for the physical credential.  

2.4.10

B.P.

If user is a minor, they do not need adult permission to provision a Digital ID version of their identity credential to their personal mobile device unless otherwise restricted by law.

2.4.11

B.P.

If a issuing authority has a policy to enable Third party individuals to have control or hold another person’s physical identity credential (e.g. partner, caregiver, parent, trusted individual), then the Digital ID credential of the person in care may be provisioned to the device identified by the third party individual.

2.4.12

B.P.

If user has entitlements for other services listed on their physical state identity/driving credential (e.g. hunting, fishing licenses), Digital ID credential should present those entitlements, and perform any lifecycle changes associated with those entitlements.

2.5.1

B.P.

Issuer, Issuer’s partners, and relying parties must ensure there is a mechanism to help ensure that the relying party only uses the data they request from the user’s Digital ID solely for the use agreed by the user.  

2.5.2

B.P.

Issuers must only provision Digital ID credentials to devices that can adequately protect the credential and then release the user authorized  Digital ID information.

2.5.3

B.P.

Issuing authorities may choose to allow a Digital ID credential to be provisioned to multiple devices controlled by a single user (e.g. phone, watch, second phone), and the issuing authority should have the same high level of confidence for each device that the correct individual has been identified during the Digital ID provisioning process.

2.5.4

B.P.

If user deprovisions the Digital ID credential, the user agrees by default to inform the issuing authority of the deprovision.

2.5.5

B.P.

Issuing authority  is able to ensure that the camera taking the selfie picture is the camera on the device that will hold the Digital ID credential.

2.5.6

B.P.

All data moved in transit between government, vendor, device is encrypted.

2.5.7

B.P.

All data moving between device and terminal is encrypted as per the ISO 18013-5 standard. 

2.6.1

B.P.

Government presents user terms & conditions for the Digital ID service in plain language.

2.6.2

B.P.

Vendor presents user terms & conditions (in the cases where it is a vendor application, and not solely a government application).

2.6.3

B.P.

In the event the issuing authority agrees to have their Digital ID provisioned to a digital platform wallet (instead of or in addition to provision to their own app), then the issuing authority needs to have a contractual relationship with the digital platform and the digital platform needs to offer T&C to the user that aligns to issuing authority’s T&C with the user.

2.6.4

Open Item

Issuing Authorities or their regional counterparts may want to place obligations on relying parties in exchange for access to the Issuing Authorities public key Master List (e.g. AAMVA DTS) or a “global entity.” 

2.6.5

Open Item

To the degree a repository of relying party public keys emerges, it may be beneficial to place obligations on relying parties in exchange for having terminals registered in the Master List.

2.6.6

B.P.

The issuing authority needs to proactively agree what the app vendor is doing with any information related to the relying party transactions, if they receive any information at all. If the issuing authority does authorize the vendor to receive any information, then terms must be established to address user privacy, commercial, and any other relevant  considerations. 

2.6.7

B.P.

Where vendor app assists user in data release and there is a contractual relationship between the vendor and the relying party, there is an opportunity for the issuing authority to pass through obligations on relying parties through the vendor.

2.7.1

B.P.

Some messages suitable to deliver in plain language during provision process (not just in T&C):

 “Your [Insert name of App] data will not be released from your device [or the issuing authority] without your permission.” 

“If you are asked to release data you feel uncomfortable sharing, do not share it” 

 “If your [mDL] data changes on record with the state, it will be updated on your [app] shortly after is is received by the [issuing authority]”

“If you believe your digital identity data is being misused, report it [here]”

2.7.2

B.P.

If the Issuing Authority allows for the storage of transaction data on the device [e.g. 2.3.4.] and/or notifies user on what (if any) transaction data may be shared off the device [e.g. 2.3.12] such configurations or options should be surfaced to the user during the provision process.

2.7.3

B.P.

Issuing authorities need to deliver clear and informative messages and options to users if the device and OS are not compatible with the issuing authority’s Digital ID requirements.

2.7.4

B.P.

During the provision attempt, one or more out of channel notifications should be sent to the owner of the Digital ID on the system of record, (text, email or letter to the address on record) notifying the individual of the provision and what action to take if this action was not taken by them. 

2.8.1

B.P.

Issuing Authority and its vendors actively pursue policies and implementations that avoid use of Digital ID credential as a channel for discrimination, including via algorithmic bias.

2.8.2

B.P.

All ecosystem participants prohibit use of digital identity data (including biometrics) for uses not disclosed to and consented to by the user.

2.8.3

B.P.

Relying party (public and private) may only request the minimum amount of data required to perform the transaction requested by the user.

2.8.4

B.P.

Obligation to notify users of any breach of the issuer authority, relying party, or their respective supplier/enablers platform(s) that hold or may have held the user’s Digital ID data. Such notification to the user is only viable to the degree the relying party holds contact information on the user. It is not recommended that the relying party obtain additional contact information beyond what is required for data minimization purposes within the transaction, solely for the purpose of notifying the individual in the event of a breach.

2.8.5

B.P.

Obligation on the relying party (or their vendors / enabling partners) to notify the appropriate law enforcement official of any breach to Digital ID data. It is not recommended that the relying party (or their vendors / enabling partners) obtain additional contact information beyond what is required for data minimization purposes within the transaction, solely for the purpose of notifying the individual or law enforcement in the event of a breach.

2.8.6

B.P.

User has right to know what information is being held and how it is being used by the Issuing Authority (and their vendor).

2.8.7

B.P.

User has right to know what information is being held and how it is being used by the relying party (and their suppliers/enablers).

2.8.8

B.P.

Some Issuing authority’s have an obligation, and the  user has right to have their information deprovisioned and their data deleted (excluding any source record that is legally held). 

Some issuing authorities may not have an obligation and the user may not have an explicit right under the law to have their information deprovisioned and their data deleted (excluding any source record that is legally held), but it may be in the best interest of the issuing authority to include this product requirement in order to future proof their service and meet user’s expectations.  

2.9.1

B.P.

Issuing Authority should ensure their Digital ID solution meets digital interface accessibility requirements (E.g. Web Content Accessibility Guidelines 2.1; Americans with Disabilities Act). 

2.9.2

B.P.

Issuing Authorities should monitor Digital ID use and assess any bias that may emerge in the marketplace, regarding acceptance of physical IDs vs Digital IDs, which may disadvantage users without eligible devices. Issuing Authorities may need to develop policies to financially support users without eligible devices/OS (e.g. like funding for devices  that allow students with less means to learn remotely; or funding for broadband access in public spaces). 

3.1.1

Req

Photo biometric taken by the Issuing Authority and issued on the physical photo ID must be taken in accordance with the standards ISO/IEC 18013-2:2020, Annex D to ensure minimum level of photo quality.

3.2.1

Req

Device key is securely provisioned during the Issuance process.

3.2.2

B.P.

The device key is bound to the Digital ID record by the issuing authority through a secure signing request between the issuing authority and the device (in 18013-5 this is the signing of the MSO requirement).

3.2.3

Req

Next expected update on the validity period (which allows a relying party to know if the Digital ID credential missed an update) will be derived based on validity period 

3.2.4

B.P.

The Digital ID credential should be automatically reprovisioned at the end of the validity period the next time the user opens the App or wallet feature. User consent for automated reprovision are included in the T&Cs (along with permissions to perform other lifecycle services proactively). 

3.2.5

Req

Expiration of license data will be consistent with the physical record (e.g. 5-7 years as defined in local law).

3.3.1

Req

Issuing authority should confirm that the natural person in control of the mobile device has legal right to provision a Digital ID.

3.3.2

Req

Remotely, user will need to prove possession of the device.

Such possession of the device is best established via un-phishable verification methods, e.g.  FIDO 2.0.  

 3.3.3

B.P.

In person, a one-time NFC token or QR code may be scanned; other one-time use mechanisms may be secure but need to be vetted to ensure security. 

3.4.1

Req

The issuing authority will follow their standard proofing process for issuance of the physical credential, or for establishing the user’s possession of a valid physical credential, as per local law.

The issuing authority has the option at the end of their proofing process or establishing the possession of a valid physical ID to choose to issue a digital version of the credential in person.

3.4.2

B.P.

For an individual new to the issuing authority and holding a physical Photo ID from a different jurisdiction. (1) Issuing Authority follows their usual process for proofing the individual, including checking the natural person against the Photo ID from the other issuing authority. (2) Issuing Authority would take a new photo biometric image for storage on the system of record and for use on the physical ID and Digital ID, as per their usual process (3) The Issuing authority would authorize the set-up of the Digital ID on the user’s device, which may be conducted via an in person binding action like scanning a QR code or NFC exchange of one-time use codes.

3.4.3

B.P.

For an individual new to the issuing authority but without a physical Photo ID from another jurisdiction, (1) Issuing Authority follows their usual process for proofing the individual without a Photo ID from another issuing authority. (2) Issuing Authority would take a new photo biometric image for storage on the system of record and for use on the physical ID and Digital ID, as per their usual process (3) The Issuing authority would authorize the set-up of the Digital ID on the user’s device, which may be conducted via an in person binding action like scanning a QR code or NFC exchange of one-time use codes. 

3.5.1

Req.

As per ISO 18013-5, the natural person is bound to the mDL though their photo biometric in the system of record

3.5.2

Req

As per ISO 18013-5, the holders device is bound to their mDL through a unique public-private key pair signed by the issuer, as also noted in 3.2.4

3.5.3

B.P.

There is no binding required in the standard between the natural person and the phone, and such capabilities are not generally available to issuing authorities today. Such a future capability might include the ability to bind a selfie taken at the time of device set-up (or triggered in Digital ID provision if not already set-up) with a selfie taken to authorize release of the Credential.

In the interim, issuing authorities have the ability to configure their apps to require, at a minimum, a PIN to be able to view or release the Digital ID.

3.5.1

B.P.

Possession of a physical ID issued by the Issuing Authority conducting the provisioning of a Digital ID, or digital version of the the physical ID.

3.5.2

B.P.

The Issuing Authority needs to algorithmically match the physical ID with an official state ID template to achieve high degree of confidence in the authenticity of the physical ID credential.

3.5.3

B.P.

Issuing authority needs to ensure the data on physical ID credential matches system of record.

3.5.4

Req

Issuing Authority need to triangulate between three photo biometrics: (1) Photo biometric held on the system of record, (2) Photo biometric on the physical ID, (3) A “selfie” photo biometric taken during the provision. Issuing authorities will want to ensure (1) and (2) match, (2) & (3) match, and (1) and (3) match to a high level of confidence.

Issuing Authorities may wish to reference an emerging certification program from the Identity Verification and Binding WG at FIDO; their goal is to set certifiable thresholds for the match between (2) and (3) to help support issuing authorities with remote issuance of Digital IDs.

3.5.5

B.P.

Issuing Authority should conduct a facial biometric verification using  a three-way photo biometric match between system of record, physical ID, and natural person performing provision. The natural person verification should include a selfie with some aspect of “liveness,” and binding by the device camera to ensure no compromise during the act of provision.

3.5.6

B.P.

Issuing authority should not use the selfie image captured during the provision process as the Digital ID credential biometric held on the device, nor used to replace the facial biometric on the system of record.

3.5.7

B.P.

If the Issuing Authority is unable to approve a remote provision with confidence, then the Issuing Authority will decline the provision outright, or direct the user to come in for an in person validation and provision or “Supervised Remote” (NIST 80063-3) provision decision (a step-up provision requirement).

3.6.1

B.P.

The issuing Authority should seek a user-centric design to the user provisioning flow. 

4.1.1

Req

Issuing authorities and their ecosystem partners should follow the ISO 18013-5 standard, and any revisions that follow.

4.2.1

B.P.

Follow OS provider and/ Device manufacturer documentation on how to have a Digital ID stored safely (encrypted) and bound to hardware security.  Such documentation is generally available from Android at the time of publishing these recommendations (Android Identity API), but guidance is not yet available from other OS/device providers so issuing authorities should continue to monitor for such guidance.

4.2.2

B.P.

Issuing Authorities considering alternative solutions without a hardware security binding component will need to have an end-to-end security model commensurate with that offered by the hardware security  binding model.

4.2.3

B.P.

Any device without hardware security or commensurate capabilities should  not be enabled for provision of Digital ID credentials, to mitigate the risk of Digital IDs being cloned or forged.

4.2.4

B.P.

To the degree that the Issuing Authority or their vendors can reasonably detect it, if a device has been jail broken an Digital ID credential may not be provisioned or would become invalidated if previously provisioned, such precaution will help mitigate the risk of attack.

4.3.1

B.P.

If the issuing authority is a US jurisdiction, Real ID flag should be supported, such that the status of the physical ID used for proofing is reflected in the status of the Digital ID held on the device.

4.3.2

B.P.

If the issuing authority is a US jurisdiction, monitor for any any DHS rulemaking that may emerge (e.g. for acceptance of mobile driving licenses at TSA/ Federal facilities e.g. Docket DHS-2020-0028 under consideration for public comment by July 30, 2021.)

4.4.1

B.P.

User can see stored Digital ID data, however such presentation should not look like physical ID credential, and no barcode should be shown (i.e. PDF 417 2D Barcode.) 

4.4.2

B.P.

User can see Digital ID transaction history consistent with Architecture decision in Section 2.3, and user preference made during set-up of the Digital ID on the App.

4.4.3

B.P.

User receives Digital ID lifecycle notifications, for example: 

“Driving privilege suspended pending renewal of physical credential, credential may be used for Identity purposes only”

“Driving privilege suspended as per state law, credential may be used for Identity purposes only”

Such lifecycle notifications to be consistent with local practice. It is recommended for Issuing Authorities to have a notification channel strategy and messages but should note that the channel may not be a legally viable channel (e.g. user may turn off all notifications and may not receive the messages.)

4.4.4

B.P.

User receives notice of each data field being requested by the relying party and has the user has the option to approve or decline sending each field before sending the data to the relying party.

4.4.5

B.P.

Issuing authority should ensure an intuitive user experience regardless of the means of exchange with a terminal (e.g. hold device within within a specific range of the terminal for NFC, or QR code readability).

7.1.1

B.P.

Issuing authority to monitor Digital ID fraud issues.

7.1.2

B.P.

Coordinate with ecosystem stakeholders to identify & remediate issues in Digital ID credential issuance.

7.1.3.

B.P.

Customer service for fraud data collection and actions (e.g. from relying parties, from users, with digital platforms, from police, vendors ).

7.1.4.

B.P.

Alerts to ecosystem members on fraud related issues (community wide vs category segments of the relying party population; digital platforms; vendors).

7.1.5

B.P.

Relying party specific alerts and call to action (e.g. terminal, software, configuration, or hardware issues).

7.2.1

Req

User consent to use Issuing Authority’s Digital ID service, usually linked to 2.6.1 acceptance of Issuing Authority Terms and Conditions.

7.2.2

B.P.

User consent to DMV specific communications (e.g. license renewal & expiry, car registration renewal & expiry, motor vehicle recall via mDL notifications)

7.2.3

B.P.

User consent to communicate regarding other State messages (e.g. state benefit programs, fishing/gun license renewal/expiry via Digital ID notifications).

7.2.4

B.P.

Customer service on non-fraud issues (e.g. messages from relying parties, from users, with digital platforms, vendors)

7.2.5.

B.P.

Training to serve state regulated relying parties that will read Digital IDs (e.g. category specific requirements e.g. alcohol, tobacco, marijuana, gaming, gun & fish licensing; requirement to update statutes to enable acceptance, and ensure those departments are informing).

7.2.6.

B.P.

Training to serve federally regulated relying parties that will read Digital IDs  (e.g. category specific requirements e.g. financial service providers, payment service providers, money exchangers, insurance, car rental) 

7.2.7.

B.P.

Training to issuing authority staff  that will read Digital IDs (e.g. DMV staff licensing, law enforcement, fish/game personnel in parks)  

7.2.8

B.P.

Communication channels for users interested in Digital ID services (e.g. state website, masterlist host website updated, DHS/TSA website, email campaigns to known users)  

7.2.9

B.P.

Inform strategic partners in the relying party community on Digital ID issuance plans & opportunities to engage.

7.3.1

B.P.

Number of attempted provisions, per day  

7.3.2

B.P.

Number of completed provisions, per day  

7.3.3

B.P.

Number of active Digital IDs, per day

7.3.4

B.P.

Number of deleted Digital IDs, per day

7.3.5

B.P.

Number of Lifecycle updates, per day

7.3.6

B.P.

Number and type of users abandonment at each step in the provision process, per day   

7.3.7

B.P.

Number and type of Confirmed Fraud, per day

7.3.8

B.P.

Number and type of Social Media comments, per day (positive and negative)

7.3.9

B.P

Number of valid active DL/IDs in circulation per month (as a baseline)

7.3.1

B.P.

Number of Digital ID presentation requests, per month, by jurisdiction

7.3.2

B.P.

Number of Digital IDs validated, per month, by jurisdiction

7.3.3

B.P.

Total number of transactions (Digital IDs and physical IDs), per month, by jurisdiction

 7.4.1

B.P.

All ecosystem entities to monitor emerging standards and policies that may impact their services e.g. ISO18013-7, ISO 23220, EU Digital Wallet, NIST, DHS rule making, national & local privacy policies.