...
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.
See notes below[Source: FIC Recommendations 8/31/2021]
4. Guidance related to Issuing Authority Right to Issue
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.3B.P. | 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. |
...
5. Guidance related to Set-up Public Key Administration [Source: FIC]Administration
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. |
...
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). |
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. |
Issuing Authority Success Criteria, Metrics, and Reporting
The Issuing Authority may aspire to 100% penetration of active Digital IDs and 100% acceptance by relying parties that need to read Digital ID data, but it will take time to reach that level of acceptance. Issuing authority reports will allow issuing authorities and their ecosystem partners to monitor performance for remediating issues, monitoring growth, assessing impact of marketing programs, and more. Ideally such reports would be standardized for cross-jurisdictional insights and benefits. Potential metrics include:”
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) |
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 |
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. |
...
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date