...
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). |
Operations
24. Guidance related to Operations: Fraud operations
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). |
25. Guidance related to Operations: Communications
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. |
26. Guidance related to Operations Issuing Authority Success Criteria, Metrics, and Reporting
...
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) |
27. Guidance related to Operations: Relying Party Success criteria, metrics, and reporting In the short term, relying parties will not be obliged to share progress reports. However, consistent reporting by relying parties will help identify issues and inform efforts to scale adoption. For example, an entity like the US DHS/TSA can provide anonymized, aggregate data on the usage of mDLs. Relying party data across relying parties could be aggregated by regional authorities or a “global entity” for a market or global view.
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 |
28. Guidance related to Operations: Emerging Policies
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. |
...