...
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.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. |
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. |
5. Guidance related to Set-up: Digital ID Channel(s) [Source: FIC]
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). |
6. Guidance related to Set-up: Architecture Requirements [Source: FIC]
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. |
7. Guidance related to Set Up: Digital Identity Credential Lifecycle
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. |
8. Guidance related to Set-up: Data Safeguards
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. |
9. Guidance related to Set-up: Contractual consent to the service
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. |
10. Guidance related to UX:
Clear messaging will help users understand their privacy choices and implications.
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. |
11. Guidance related to Set-up: Legal
These Recommendations reflect the common high bar in privacy legislation that may help identity ecosystem partners “future proof” their products & services.
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. |
12. Guidance related to Accessibility of mDL Solution
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). |
13. Guidance related to Provision to User Device: Photo ID Issuance
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. |
14. Guidance related to Provision to User Device:Public key administration
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 (whichallows 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). |
15. Guidance related to Provision to User Device:Establish user control of device
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. |
16. Guidance related to Provision to User Device: In-person proofing person identity
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. |
17. Guidance related to Provision to User Device: Binding
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. |
18. Guidance related to Provision to User Device:Remote proofing person identity
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). |
19. Guidance related to Provision to User Device: Provision UX
3.6.1 | B.P. | The issuing Authority should seek a user-centric design to the user provisioning flow. |
20. Guidance related to Credential storage & management: Compliance with standard ISO 18013-5
4.1.1 | Req | Issuing authorities and their ecosystem partners should follow the ISO 18013-5 standard, and any revisions that follow. |
21. Guidance related to Credential storage & management:Architecture requirements
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. |
22.Guidance related to Credential storage & management:Local Digital ID Capabilities
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.) |
23. Guidance related to Credential storage & management: UX
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). |
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
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) |
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. |
...
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date