...
Ref # | Page# | Line # | Comment Type: Editorial or Technical | Comment / Request | Proposed Edit / Change | WG Accepted |
---|---|---|---|---|---|---|
1. | 12 | 222-223 | Editorial or Technical | Include your comment | Recommend a change | WG lists their finding here |
1. | Section 2.2.4 | Editorial | Suggested addition of “For example, in most use cases, marketing should not be the sole or primary purpose for the collection of mobile credential data.” | Remove addition and refrain from referencing marketing/any other use case | Sentence deleted. | |
2 | 9 | The diagram is a bit of a mess with the line numbers interfering with the graphic. | Line numbers removed from release version | |||
3 | 10 | 195 | Line 195, the use of the word “her” in the paragraph. In this day and age “him and her” are a questionable way to describe the human condition. |
| ||
4 | 11 | 204 | socio-technical, in other places this is one word. | Replaced socio-technical with sociotechnical throughout | ||
5 | 19 | 410 | missing a period at the end. | Fixed | ||
6 | 20 | 455 | The word “Current’ got my attention. Is it not possible that ‘old’ information (however old is defined), still accurate information, could still be relevant to parties interested in the information on the mDL and presented by the Holder for a specific purpose? (I suspect many minds brighter than mine already had this discussion and decided that “Current” was OK in this explanation. Oh well.) Line 480 also mentions “currency.” Something could be “accurate” but not “current.” The accurate ‘old’ information could still be relevant. (?) | Added this note: NOTE: For these requirements, “current” is not a measure of how old the information is. For example, a home address may be current if it has not changed in 10 years and is still the ‘current’ address. | ||
7 | 23 | 537 | I’m not too keen on using the word “downstream.” I know what it means and what ‘you’ are trying to say, but I’m not sure that its use in a technical paper is appropriate. I think it is a shortcut for perhaps a longer phrase that might better define what you are trying to say here. “Downstream” is a corporate term, but not widely used by the average person. (?) | Original: NOTE: Where Verifiers use Holder data for downstream purposes identified, whether or not this is identified in their Notice, the Verifiers should implement a system or a process to allow the Holder to understand what data has been processed. Changed: NOTE: Where Verifiers use Holder data for other purposes, whether or not this is identified in their Notice, the Verifiers should implement a system or a process to allow the Holder to understand what data has been processed. | ||
8 | 26 | 643 | I would insert “(PIA)” right after “A Privacy Impact Assessment”. In my property world our style is that when there is the first use of a term, as we have in this case, and subsequent use of the acronym, that the acronym is defined right after the first use of the full term. | (PIA) added | ||
9 | 28 | Should the “Note” in “Biometric” end with something like this: “…retina scans, or other features, or a combination of features.” ?? Are there cases, or will there be cases, when more than a singular biometric feature will be used to establish identity of a natural person? Seem possible to me, although I do not have a current example for you. | Updated to read: Note: Biometrics are treated throughout this document as inherently sensitive data, and can include facial images, fingerprints, retina scans, or other features or combinations of features. | |||
10 | 30 | “Holder” then “Note”, I was taught by a bright lawyer I know that “and/or” is poor form and lazy use of language. On the other hand I am not offering a ‘correction.’ I’ll leave that up to the group. | Updated note reads: Note: Delegates are handled elsewhere in this document. In those cases, the delegate may ‘hold’ the device or use the app on behalf of the natural person. | |||
11 | 30 | “Identity proofing. Why the three dots … before “This is the process…” ? And to be consistent, the word “proofing” in the “Term” column should be in capitalized. | No change. The ellipsis indicates that the words following are a continuation of the text from the source. | |||
12 | 30 | “Identity Provider” Does the “AKA” here stand for the usual “also known as”? And I assume “SP” Stands for “Service Provider.” ? And, is it proper to keep the little footnote number at the end of the definition when there is no footnote shown on this page? | Removed the footnote number, but left the rest unchanged as a quote from the indicated source. | |||
13 | 31 | I think to be consistent with your style that “Mobile Driver’s License” should have a cap “D” and “L”. And I have a question about the AAMVA definition. I have concern, maybe a question, about the word “same.” Is it not possible, even likely, that there will be or could be a ton more data on an mDL than on a ‘plastic’ driver’s license? | Changed Mobile driver’s license to mobile Drivers’s License. The rest is unchanged and can be discussed by the group. | |||
14 | 32 | Cap issue with the Term “Operational Circumstances”. Same for the “Personal Information” below. | Changed to Title Case | |||
15 | 33 | Relying Party.” Here you use “IDP” but on page 30 you use “IdP”. I think you need a lower case “d’” here. | Unchanged. This was from the source IDPro Body of Knowledge. Agree not completely user friendly. | |||
16 | 34 | OK, I know what “GDPR” is. But much of the world does not. As this is first use in this paper, you should spell it out. | Done | |||
17 | 34 | Under “Term” “Design should be a cap “D”. | Fixed | |||
18 | 35 | “and/or” shows up again. | Fixed | |||
19 | 36 | Line 679 Missing a period at the end?? | Fixed | |||
20 | 37 | Line 694. I would remove the word “written.” A sign is a sign, written or electronic. | Changed | |||
21 | 37 | Line 697 Missing a period at the end?? | Fixed | |||
22 | 6 | 109 | An individual's privacy is protected when compensating controls implemented by the recipient protects the individual's data, not when the controls may protect the individual's data. | No change - to discuss | ||
23 | 6 | 113 | This wording includes transactions that are not in person at all. Strike "primarily". | Deleted | ||
24 | 10 | 196 | There is only one triangle. | No change - the inner triangle is Issuer, App, and Reader components; and the outer triange are the Issuer, Verifier, and Holder organisations/individuals. “The distinction between the two triangles is between electronic connections between components and relationship connections between individuals and organisations.” added | ||
25 | 10 | 200 | There is only one triangle. | No change - the inner triangle is Issuer, App, and Reader components; and the outer triange are the Issuer, Verifier, and Holder organisations/individuals. “The distinction between the two triangles is between electronic connections between components and relationship connections between individuals and organisations.” added | ||
26 | 14 | 266 | "...at... the Holder presents..." does not read right. | In some operational contexts, the presentation of the credential is the consent action. | ||
27 | 14 | 282 | Hard to follow this sentence. Possible alternative: The Issuer shall ensure that the Mobile Credential app into which it provisions allows the Holder to share data elements selectively. | |||
28 | 14 | 289 | Consent to present/share is not the same as selective release. Consent to present/share does not imply selective release. It is not clear how the note relates to the requirement. | |||
29 | 15 | 30 | If a Verifier or Issuer is not a system developer, this requirement as worded does not apply to a Verifier or Issuer. What is the requirement on a Verifier or Issuer (to which an auditor can hold them)? | No change: It is the case that Systems Developers working on systems to be used by Providers and Developers can set the defaults for the systems which can be changed as part of the implementation. What this requirement means is that the Issuers or Verifiers who want to change the defaults as part of their implemention need to document the reasons. | ||
30 | 16 | 331 | Just "Providers"? Is a wallet provider something different from a provider? | “Wallet” deleted | ||
31 | 16 | 333 | The Provider shall communicate all the data use information received from the Verifier. Requirements for what a Verifier must communicate must be addressed separately (and elsewhere). | |||
32 | 17 | 343 | not engage? Refrain from could be interpreted as leaving some wiggle room. | It is ‘shall refrain’ No wiggle room in my view. | ||
33 | 17 | 346 | This is not regarded as...? | Cooperation for the purpose of reasonable business risk mitigation is not necessarily a collusive practice. | ||
34 | 17 | 352 | This appears to be at odds with the requirement. It implies that it would be possible to use legitimacy to normalize unacceptable business processes. | |||
35 | 17 | 357 | What reason would there be for verifiers to not follow regulators’ guidance (unless the guidance allows deviation, in which case that would still be guidance)? What will we lose if this sentence is deleted? | |||
36 | 17 | 359 | This means that there is no requirement on Issuers or Verifiers. Is this correct? | |||
37 | 17 | 362 | Does this mean that Providers and Vendors should not develop training by themselves? Who are the trusted governance authorities? | |||
38 | 18 | 388 | System developers, including Providers and Vendors | |||
39 | 18 | 389 | indirectly from other sources As worded now, a system that includes personal information of a Holder where the information was sourced exclusively from sources other than what was provided directly (via a Mobile Credential) by the Holder are subject to this requirement. This would make an airline reservation system that has nothing to do with a Mobile Credential subject to this requirement. I surmise that we do not want to do that. | |||
40 | 19 | 412 | System developers, including Providers and Vendors | |||
41 | 20 | 449 | System developers, including Providers and Vendors | |||
42 | 21 | 470 | It is not clear to me what this means. | |||
43 | 22 | 500 | Holder? | Changed | ||
44 | 22 | 500 | access and request | |||
45 | 22 | 507 | System developers, including Providers and Vendors | |||
46 | 22 | 509 | access their information in the system | |||
47 | 22 | 510 | means | Changed | ||
48 | 22 | 510 | aware of the system's operation Providers and Verifiers shall set defaults in their systems that ensure that the Holder is being informed of the system's operation. | |||
49 | 22 | 523 | correct, amend, or delete their data where it is inaccurate | |||
50 | 22 | 524 | data controllers and individuals | |||
51 | 23 | 530 | Credentials shall be made available to all Holders with rights granted by the Issuer | |||
52 | 23 | 535 | participate in decisions | |||
53 | 23 | 537 | purposes identified, whether or not this is identified in their Notice | |||
54 | 23 | 539 | understand | |||
55 | 23 | 541 | shall | |||
56 | 23 | 541 | granted | |||
57 | 23 | 544 | System developers, including Providers and Vendors | |||
58 | 24 | 579 | Where law requires | |||
59 | 24 | 582 | System developers, including Providers and Vendors | |||
60 | 26 | 626 | System developers, including Providers and Vendors | |||
61 | 26 | 635 | regulatory | |||
62 | 26 | 643 | A Privacy Impact Assessment shall be conducted for any system that processes Mobile Credential data. The first Note is not sufficient grounds for an auditor to require anyone to do a PIA. | |||
63 | 26 | 652 | privacy compliance for regulators where requested | |||
64 | 27 | 657 | No requirement on Verifiers? | |||
65 | ||||||
66 | ||||||
67 | ||||||
68 | ||||||
69 | ||||||
70 | ||||||
71 | ||||||
72 | ||||||
73 | ||||||
74 | ||||||
75 | ||||||
76 | ||||||
77 | ||||||
78 | ||||||
79 | ||||||
80 | ||||||
81 | ||||||
82 | ||||||
83 | ||||||
84 | ||||||
85 | ||||||
86 | ||||||
87 | ||||||
88 | ||||||
89 | ||||||
90 | ||||||
91 | ||||||
92 | ||||||
93 | ||||||
94 | ||||||
95 | ||||||
96 | ||||||
97 | ||||||
98 | ||||||
99 | ||||||
100 |