John,
To the extent that I may have a vote, I vote to approve the document, with suggestions. My suggestions follow. I’d be happy to discuss any of them if needed.
In UC3, I believe that (at this time, given what we say in UC2) the biometrics collected are explicitly not collected “on-device”. They are biometrics included in the identity credential provided by the Holder. I suggest striking “on-device” in line 215.
There is statement on line 447/448 that a Verifier may limit the Holder’s access to the Holder’s data. I suggest that this statement be deleted. My understanding is that we are talking about information the Holder shared with the Verifier, or metadata directly related to the action of sharing. I do not think any of this should ever be withheld from the Holder.
<!—start sidebar-->
This also raises an interesting point. If a Holder shares identity and driving privilege information with a law enforcement officer, and the officer associates this identity information with information about a traffic violation, does the Holder have a right to access this linkage (and the violation information) because the holder shared identity and driving privilege information? Or say the law enforcement officer associates the Holder’s identity information with the identity information of the driver of the other vehicle in a 2-car crash. Does the Holder have a right to access this linkage (and the identity of the other driver) because the holder shared identity and driving privilege information? I am fairly confident that questions like these are not new, so am eager to hear what the experts say.
<!—stop sidebar—>
Line 553: It is not clear why this is prefaced with “If an Issuer permits…”.
Line 556: Since the credential is signed by the Issuer, and there is of yet no standardized way for the device to perform trustable data calculations at transaction time, ensuring that minimized data elements are present in the credential is an Issuer responsibility and not a Provider responsibility. The Provider’s responsibility in respect of data minimization is to provide the Holder with the means to prevent sharing more than the Holder feels comfortable with.
Line 567: I believe the reference should be to the Provider Solution rather than to the Provider Service.
Line 581/582: See comments above. I am not aware of any standard way for the device to perform trustable data calculations at transaction time. I suggest that the example be qualified accordingly. That is, explain that calculations by the Provider Solution is contingent on the Issuer (or Verifier) trusting the Provider Solution to do this.
Line 639, last 2 sentences of the 1st paragraph: It is not clear what these two sentences say. If it is intended to say what I think it wants to say, I would like to point out that an Issuer should provision into any Solution, regardless of the relationship (or absence thereof) with the Verifier, only if the Issuer is satisfied that the Solution and the Solution Provider meet the necessary conditions (including privacy requirements). It is up to the Issuer to confirm what those conditions are and how it will ensure compliance. I therefore believe that this is what we should convey here, i.e. that the Issuer has a responsibility to ensure that both the Solution and Solution Provider comply with the necessary requirements before (and after) provisioning takes place.
Row 695 and 699: It is not clear what “ancillary data” would be for a Verifier (it is clear what it would be for an Issuer). Perhaps add an example?
Lines 826 to 828: I believe the genesis of this requirement is an item in the AAMVA mDL Implementation Guidelines that states (paraphrased) that if a person holds more than one mDL and chooses to keep separate transaction logs, visibility of the log file should not enable to infer the existence of the other log file. This requirement was created in response to a comment from the ACLU that pointed out that if a Holder’s log file were to become known to someone other than the Holder (e.g. if forced, as a condition of entry into a country, to show the log file), it will not reveal the existence of the other mDL instance or its transaction log.
Line 852: While a Next Steps section could be helpful, I agree with the comment that the current content is perhaps not a good fit.
Thanks,
Loffie Jordaan
Business Solutions Architect
Phone: 703.908.5864
Email: ljordaan@aamva.org
From: John Wunderlich <john@wunderlich.ca>
Sent: Tuesday, October 31, 2023 17:18
To: WG PEMC <wg-pemc@kantarainitiative.org>
Subject: [WG-PEMC] Implementor’s report for workgroup vote
WARNING: This email originated from outside of AAMVA. Do not click on links or open attachments unless you recognize the sender and know the content is safe.
Please find attached the Early Implementors Draft for workgroup vote:
Next steps:
1 Workgroup Votes:
- Vote Approve
- Vote Approve with suggestions (include specific suggestions for final editing)
- Vote Not Approve
2. Final Editing by leadership team (assuming majority of votes cast are Approve or Approve with suggestions)
3. Submit for publication
On the agenda for tomorrow:
- Developing a cadence and calendar for asynchronous development of requirement
- Review of voting process
Have a better than expected day,John Wunderlich
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
