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.
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.
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,
[Logo, company name Description automatically generated]http://www.aamva.org/
Loffie Jordaan
Business Solutions Architect
Phone: 703.908.5864
Email: ljordaan@aamva.orgmailto:ljordaan@aamva.org
aamva.orghttp://www.aamva.org/
[Icon Description automatically generated]https://www.facebook.com/AAMVA/[A picture containing text, wheel, gear Description automatically generated]https://twitter.com/AAMVAConnection[Icon Description automatically generated with medium confidence]https://www.youtube.com/channel/UCrW3jQf3p_25zeK9EQbCrAA[A picture containing graphical user interface Description automatically generated]https://www.flickr.com/people/aamva/[Icon Description automatically generated]https://www.linkedin.com/company/aamva/[Icon Description automatically generated]https://www.instagram.com/aamvaconnection/[Icon Description automatically generated]https://aamvacast.podbean.com/
From: John Wunderlich
