Ref #
Page#
Line #
Comment Type: Editorial or Technical
Comment / Request
Proposed Edit / Change
Status
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
65
6
has created a set of
requirements for stakeholders to respect the privacy of individuals
Replace with: "has created requirements for good practices related to respecting an individual's privacy. "
Text replaced
66
6
(also referred to as “Holders”)
holding or using mobile identity credentials— such as a mobile Driving License (mDL)
replace with: "These individuals who use mobile identity credentials such as mobile Driving Licenses (mDL) are also known as "Holders". "
Replaced
67
6
— primarily
for in-person transactions and transactions with an in-person component.
Replace with; "The good practices apply primarily to in-person transactions and transactions with an in-person component."
Replaced
68
6
principle’
replace with: "principal"
Replaced
69
6
The stakeholders and their
relationships in this extended mobile identity credential system version are captured below.
Delete sentence - it is not relevant to the topic of the introduction (it is about the structure of the report)
Deleted
70
7
will be helpful to
replace with: "can be used by"
Replaced
71
7
Kantara Mobile
Assurance Statement
Remove this reference unless it forms a critical role in this report. The Abstract seems to indicate that it is not about "privacy enhancement" but about app installation.
Deleted Row
72
7
etc
Do not end a list with "etc. Use a structure like "Types of identity credential could for example include a student card, or a membership card, or a driving license.
The proper use of et cetera (and the rest) is to indicate that a list is incomplete and that there are other items other than the ones explicitly mentioned.
etc is used correctly here
73
8
etc
See previous comment about lists and "etc"
etc. is used correctly
74
8
For this report, a mobile version of the credential is a machine-readable1 digital
version that can be stored on a mobile device such as a phone and then presented using that
device instead of the physical credential
This text seems out of place - it doesn't really relate to "actors".
Deleted
75
8
provision a
Mobile Credential to a Holder
Does the "issuer component" provision anything to the "holder" themselves? Don't they issue/install/transfer (whatever) the credential to the Holder's device?
This is very important because other organizations use "holder" to mean the software, not the person.
In the next definition “Holder” is defined as a natural person. The technical component corresponding to the holder is the “App” which in many cases is likely to be a wallet but could be a purpose built app for the particular credential.
76
8
Requirements on Issuers should be read to apply to Vendors to Issuers
This sentence is hard to parse. Are you trying to say that Issuers should apply these requirements to their vendors?
You’re right. This is hard to parse, and doesn’t make sense in this context. Will delete it.
77
8
Holder: The Holder is the natural person whose attributes are contained in a Mobile
Credential.
Is it clear that this report only covers credentials on the person's device that pertain to the holder? Obviously there could be credentials for other subjects present - it's ok to constrain the scope...
I think it’s clear, since the point of requirements is to respect Holder Privacy.
78
8
Verifier: The Verifier of the Mobile Credential is the organization that receives the Mobile
Credential from the Holder in a digital transaction.
What component 'verifies' the credential? Because 'verify' is not the same as 'read'.
Which Actor receives the information contained in the credential?
Changed the first bullet to ‘read and verify the Mobile Credential’
79
8
depend on their Providers
Shouldn't this be "depend on their Vendor"?
80
8
Sometimes, the Provider and the Vendor in a transaction may be the same
organization.
I don't like this differentiation of Vendors v Providers. Why is this done this way?
I make the distinction between Vendors who have a B2B relationship with Issuers and Verifiers as opposed to Providers who have a B2C relationship with Holders.
2
9
The diagram is a bit of a mess with the line numbers interfering with the graphic.
Line numbers removed from release version
81
9
The primary relationship between the key actors is shown in the following diagram
Not sure whether this figure is useful or not. If it is used, then the prior list should be separated into 'key' and 'not key' actors otherwise the reader wonders what makes these particular actors 'key'.
Fair enough. Will delete.
82
9
The Issuer ‘provisions’ the Holder with a Mobile
Credential.
The Holder presents the Mobile Credential to a
Verifier.
The Verifier reads and verifies the Mobile
Credential.
This text is slightly different than the descriptions above - should be the same/aligned.
See comment above. This diagram will be deleted.
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.
- John Wunderlich Will attempt to update before release to “their”
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.”
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.”
83
10
Respecting privacy in a Mobile Credential ecosystem is a sociotechnical problem3 that requires
stakeholders to consider multiple design and operational factors.
Pedantic: is "respecting privacy" a "problem"? Does every stakeholder have to consider factors? How does a "stakeholder" differ from an "actor"? in the diagram I don't think I see any entities that are not Actors.
Changed to “Constructing a Mobile Credential ecosystem the respects Holder privacy…
84
10
The figure above
Probably better to say "Figure 2 shows..."
4
11
204
socio-technical, in other places this is one word.
Replaced socio-technical with sociotechnical throughout
1.
12
222-223
Editorial or Technical
Include your comment
Recommend a change
WG lists their finding here
85
12
The following are derived from
ISO/IEC 29100 Privacy Framework4, also captured in ISO/IEC 18013-55
. Similar lists can be found in
the United States6, EU7, and Canada8.
Consider adding an Annex that has the actual list of principles and their explicit.
In my view this would be redundant as the list is visible in the table of contents, and each principle section starts with a statement of the principle.
86
12
taken into consideration to respect the privacy of individuals. We recognize that each requirement
may be related to more than one privacy principle, so implementors and reviewers should review
all requirements for their particular use case.
Replace with: "The privacy principles and related requirements should be considered as a whole."
Changed to We recognise that each requirement may be related to more than one privacy principle, so implementors and reviewers should consider privacy principles and related requirements as a whole.
87
12
NOTE: Most data protection or privacy regulations are designed to apply to processing personal
information by organizations or governments and to address an information power imbalance
between individuals and the organizations or governments that process their data. Here, in the
case of Mobile Credentials, the individual's autonomy is down to accepting (or not) the
provisioning of a Mobile Credential and choosing whether to present their Mobile Credential
when asked. Privacy considerations compensate for this lack of digital autonomy and ensure
“fair” processing of personal information.
Not sure I like this note... the sentences don't really hang together - first talks about regulations, power imbalance. Then says that individual autonomy has only one or two components. Then says that "considerations" compensate for a new thing: "digital autonomy" - and that these considerations have a profound effect on data processing (they do not - the orgs implementing them probably have more)
88
12
The convention in this report is that the requirement is a
‘shall’
, and any NOTE that may accompany the requirement is a ‘should.’ In many use cases – for
regulatory or policy reasons – those NOTEs may be normative rather than informative and should
be understood in the use case context.
Cannot use this convention. We should try to align with ISO style - NOTE is purely informative and no 'requirements language' is permitted in a NOTE. It's too confusing to figure out what parts an org needs to do.
Each section below starts with a description of the privacy principle. These descriptions inform the normative requirements that follow. The convention in this report is that the requirement must have at least one ‘shall’ statement. This statement may be accompanied by ‘should’ statements that assessors or organisations can determine to apply in the context of their use case. Organisations that do not apply the ‘should’ statements and seek to attest to their conformance with the requirement should document the reasons for not applying the ‘should’ statements.
89
12
We plan to establish a certification process to enable stakeholders to make claims about their
products based on these requirements.
It would be better to say that the stakeholders can attest to their implementation relative to requirements. Certification is simply a formalized, independent mechanism to do the same thing.
90
12
NOTE: Where implementing a particular requirement or part of a requirement violates local
regulations, that requirement should be regarded as moot.
This statement should be deleted. Implementers must always be lawful - it does not matter what this document says to do or not do.
91
13
only processes
personal information with the individual's opt-in consent,
This sounds like an absolute statement - that consent is the only basis for collecting and processing PII. This is not workable in the real world - consent abuse is rampant - by requiring consent for all cases the situation for people is not improved.
92
13
unless otherwise required by law
see prior comment about reference to legal applicability
93
13
two elements to consider here
the 'two' elements are not clear in the text - can you reword to make the two thing more obvious? or delete this sentence because it adds no extra meaning.
94
13
Providers
I thought "providers" only service holders?
95
13
Where processing Mobile Credential data is required by law, consent should not be sought as the
choice is moot. Compensatory controls related to notice and transparency must be established
instead.
This formulation is confusing. Need to figure out how to express that data processing must be authorized, and one (maybe preferred) way to obtain authorization to process is through the mechanism of consent. Otherwise we must repeat all the carveouts for other authorization to process mechanisms (like the law).
96
13
NOTE: In some use cases, the cognitive overload on Holders (i.e., being incessantly asked for
consent) will reduce the effectiveness of consent and choice on Holder autonomy, which the
affected stakeholders should address.
This is great, but not very helpful.
97
13
NOTE: What can be used as consent for processing will vary between jurisdictions. We use ‘valid
consent’ to recognize that consent is jurisdictionally or contextually variable. At a minimum,
consent must be obtained in a manner that meets the legal requirements in the jurisdiction
where the consent is sought.
You really cannot say this - implementers must abide by the law in all cases.
Also "valid consent" is not consistently used in the text which opens the question about other forms of consent.
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.
98
14
consent may be inferred
is this really true?
99
14
For
example, a sign behind the register stating age over 21 will be verified for purchase, but no
records will be retained.
Can you use a better example? this one is very incomplete... a good public notice would have more information than what is in this text.
100
14
NOTE: In some use cases, the possibility of a coerced presentation exists, and Implementers are
encouraged to explore options for the Holder to identify coerced presentations.
Although this might be true, does it belong in a principle about "context"?
101
14
NOTE: This is one of three requirements related to selective data release.
so what? this adds no meaning. delete.
102
14
NOTE: Selective data release capability does not warrant the Verifier limiting the data request.
I do not understand what this means.
103
14
NOTE: Holders’ selective release is provided in person by the Holder choosing to present their
device.
I'm not sure this is always true. And, I thought mobile credentials are presented. Is this saying that a device can be presented too?
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.
104
15
NOTE: Providers and Vendors should provide documentation or training for their systems to
support opt-in consent as the default.
provide to who?
105
15
NOTE: Where Issuers or Verifiers opt to install systems based on opt-out consent or where consent
is not sought for other reasons, Providers and Vendors should provide training to help Issuers
and Verifiers document their choices.
Maybe these notes about system design and implementation should go together in some other place?
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).
106
16
The purpose should be legitimate – i.e. it
must comply with relevant legislation
I don't believe that this is the meaning of "legitimate processing" - it cannot simply be "comply with the law". Processing legitimacy is relative to authorization to process. And sometimes that authorization comes about directly from statues or regulations - but sometimes not.
"respect for individual privacy" has little to do with laws.
107
16
Such data must only be processed where there is a specific
legal requirement that permits the processing or where there is a reasonable business purpose
that meets the privacy expectations of the credential holder.
This sentence support the previous comment about 'legitimacy'. You say "either law or reasonable business reason" are OK.
108
16
or confidential
delete - do not introduce a new wrinkle
109
16
the purpose for which that Mobile Credential was
created, as well as the purposes for which the information in that credential may be collected,
shall specify what processing of that information may occur
This is confusing - is it a requirement? I'm not quite certain what is trying to be said...
110
16
kinds of data
Pedantic: are we dealing with data or information - the text seems to use the terms interchangeably.
111
16
legal requirement
this repeats the error of the previous paragraph. remove the duplication.
112
16
reasonable business purpose
duplicated paragraph
113
16
reasonable
Really don't like this formulation of reasonableness.
Secondary information uses in this example are often for convenience - if evidence is requested then a convenient tamper-resistant piece of evidence is an ID Card. Or, the government-issued ID evidence must be produced on demand as stated in statues (which means it doesn't count as 'reasonable' in your description)
114
16
legally specified
maybe "authorized by law"
115
16
NOTE: To inform Holders of a Verifier's retention policy and the data requested, the Provider should
communicate to Holders how the Verifier has claimed they will use the data and for what
duration they expect to retain it.
Is this not simply the "privacy notice"?
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?
116
17
regulatory capture
I'm pretty sure "regulatory capture" is misused here?
117
17
NOTE: Stakeholders often cooperate or share data to prevent fraud or identity theft. We do not
regard risk mitigation as a collusive practice.
Again - this note pertains to authorization to process - if collusion can never be an authorized processing, then say that instead of this.
118
17
NOTE: ‘Legitimacy’ is determined in the context of the relevant regulations or the Holder's view.
Legitimacy should not be used to normalize business processes that regulators or average
users would not regard as legitimate. For example, in most use cases marketing should not be
the sole or primary purpose for collecting Mobile Credential data.
Not really - 'legitimacy' is related to authorization and permission - if the holder believes that even though the verifier is authorized to collect data for some purpose, the processing is unwanted/unwelcome, then the processing is still 'legitimate' but will be declined or whatever.
119
17
NOTE: Where regulators understand ‘legitimate purpose’ as a legal basis for processing, they will
often provide guidance on determining whether a purpose meets their regulatory
requirements. Verifiers should follow that guidance in their determinations.
This seems to be a different sense of the term 'legitimate' than used previously. I don't think the concept of 'legal basis' has been described yet in this document.
120
17
trusted governance authorities
this seems to be a new entity?
121
17
Any such data should be obtained by lawful and fair means and, where possible, with
the knowledge or consent of the Holder.
This seems to be a better way to talk about consent.
38
18
388
System developers, including Providers and Vendors
This means there is no requirement on Verifiers. Is this correct?
39
18
389
indirectly from other sources
Why is information that is collected by means other than the Mobile Credential in scope for this document?
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.
122
18
NOTE: Verifiers only request the strictly necessary personal information to provide the services
according to legitimate purposes for data processing. When no identification of the user is
needed, Verifiers can accept the isolated proof of attributes via selective disclosure
techniques or, when viable, zero-knowledge proofs.
no argument about what this says - but it's a very dense and jargon-filled thing.
123
18
NOTE: To avoid excessive data collection, the Verifiers' requested data fields should be mapped to
the minimum required to meet their attested use case.
Is this implementation detail necessary? Are there other ways to avoid excessive data collection that are equally valid?
124
18
necessary for
the Mobile Credential to function in fulfillment of the purposes for which the Issuer issued the
Mobile Credential.
Does this statement preclude the idea of secondary uses?
125
18
stated
'legitimate' not 'stated'
126
18
Regular reviews should be conducted to ensure that the data held is
still pertinent and sufficient for the purposes, and any unnecessary data should be deleted.
this looks like a requirement
127
18
unnecessary
'unnecessary' is an unnecessary modifier - delete the word.
5
19
410
missing a period at the end.
Fixed
40
19
412
System developers, including Providers and Vendors
As worded, there is no requirement on Verifiers. Is this correct?
128
19
NOTE: Verifiers should only combine presented data to identify the user or establish patterns if the
user has been previously informed and has consented.
Why not say 'unless re-identification is a stated purpose' instead of hanging it all on 'consent'. dark patterns etc.
129
19
NOTE: The minimum personal information necessary may include metadata or other elements
necessary for auditing or regulatory oversight, depending on the use case.
is metadata considered to be Personal Information? what's the current understanding?
130
19
NOTE: Verifiers should not store personal information unless the Holder has consented to a
specific purpose (e.g., marketing) or is required for accountability.
this note does not support the requirement - delete.
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.
41
20
449
System developers, including Providers and Vendors
This means there is no requirement on Verifiers. Is this correct?
131
20
NOTE: Many systems generate audit trails, which may contain personal information. Those audit
trails or logs should be treated as separate personal information assets and protected
accordingly.
why not require that PII is segregated from operational data/logs to avoid unwanted exposure?
PII is PII - doesn't matter what form or location. So this is interresting information but should have no additional protective effect on well designed systems.
132
20
NOTE: Verifiers may include the retention period as part of their consent request.
this note is simply a restatement of the requirement. delete
133
20
NOTE: Verifiers should communicate to the Holder the retention period for personal information or
confirm that personal information will not be retained.
this note is simply a restatement of the requirement. delete
134
20
Accuracy is the foundation of a quality management system
are you implying that mobile credential systems should implement quality management systems as well?
42
21
470
It is not clear to me what this means.
135
21
what they know about Holders
perhaps state this as "what information they have about Holders"
43
22
500
Holder?
Changed
44
22
500
access and request
I still have heartburn with this recommendation. It implies that we have decided that the providing the Holder with the ability to request modification or erasure is more important than the PII that would have to be stored to make this possible. It means that instead of only storing a holder's portrait image and the fact that the holder is over 18, the Verifier now also has to store additional PII to make it possible to identify the record in case the Holder requests modification or erasure.
45
22
507
System developers, including Providers and Vendors
No requirement on Verifiers?
46
22
509
access their information in the system
Does this duplicate 2.7.2? It appears to be very similar to the 2nd note under 2.7.2.
47
22
510
means
Changed
48
22
510
aware of the system's operation
Why not then include this in the requirement? For example:
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
This arguably does not apply to Verifiers or Providers. These entities get transaction data from an Issuer, which are historical facts. You cannot change history.
50
22
524
data controllers and individuals
between Verifiers and Holders? "data controllers" is not defined.
136
22
guarantee
"guarantee" seems like an overstatement or unachievable condition
137
22
NOTE: Open in this context should mean that the Holder is aware of the system's operation.
perhaps modify the requirement in a way that eliminates the need for this note?
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.
51
23
530
Credentials shall be made available to all Holders with rights granted by the Issuer
This is a policy matter that is unrelated to privacy. This is out of scope of this document.
52
23
535
participate in decisions
I still am concerned with this wording. It implies that a Holder can, after agreeing to processing (i.e. effectively concluding an agreement with the Verifier when sharing information), change the terms of the agreement with the Verifier. I believe this places an undue burden on the Verifier. If the Holder becomes uncomfortable with the agreement, the Holder can nullify the agreement, rather than "participate in the decisions".
53
23
537
purposes identified, whether or not this is identified in their Notice
How can purposes be identified if it is not identified in the Notice?
54
23
539
understand
How is this note applicable to the requirement? The requirement is about participation. The note is ostensibly about understanding. Participation and understanding are not the same.
55
23
541
shall
We should not have "shall" statements in a note.
56
23
541
granted
What if this is minimized data, e,g, only a portrait image and an age over statement?
57
23
544
System developers, including Providers and Vendors
No requirement on Verifiers?
138
23
NOTE: Processes and systems should be designed to accept and process individuals' requests for
correction or deletion.
this note does not appear to be relevant to the requirement.
139
23
and participate in decisions about
processing
need to be way more precise about what this means.
140
23
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.
this does not sound implementable or reasonable.
141
23
NOTE: Where a person requests access to records held by the Verifier, access to Mobile Credential
data provided by the Holder shall be granted. However, the Verifier may consider limiting
access to other records to protect the privacy of others or as may be required by law.
is this a requirement?
142
23
data protection principles
"data protection"? or "privacy"?
143
23
Organizations shall
assume a duty to care for the personal information in their custody and control.
this sounds like overreach. delete
58
24
579
Where law requires
Unless we update to say that this applies ONLY where law requires, I am of opinion that this is a superfluous requirement. Local law would always apply, regardless of what this document says.
59
24
582
System developers, including Providers and Vendors
No requirement on Verifiers?
144
24
Verifiers shall identify themselves with the Holder with enough details about the transaction to help
the Holder decide whether to proceed.
NOTE: For the Holder to proceed with a transaction, the first step is for the Verifiers to identify
themselves in context. A context might be admission to a stadium. Another context might be a
medical office. The Holder can verify that they are in the stadium or the doctor’s office, and the
Holder Agent should be able to validate and record that information.
Theres something just not right about this one.
145
24
Where law requires, Verifiers shall maintain appropriate registries with the minimum required data
set to ensure access to regulatory and legal authorities for accountability.
nope. if the law requires it we don't have to say anything.
146
25
All identifying data shall be transacted through encrypted channels. To protect the confidentiality
of Holders, Issuers, Providers, and Verifiers shall only transact identifying data through encrypted,
secure channels to prevent exposure to third parties.
i understand the concern. However this is the first time non-PII is described. might need text in the introduction to support this.
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
60
26
626
System developers, including Providers and Vendors
No requirement on a Verifier?
61
26
635
regulatory
I still maintain that compliance with regulatory requirements are out of scope. Regulatory requirements have their own guardians. No need for this document to police that.
62
26
643
A Privacy Impact Assessment shall be conducted for any system that processes Mobile Credential data.
By Verifiers, Providers and Issuers?
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
See comment above. Regulatory requirements have their own watchdogs. Checking that regulator requirements are met is not a job for this document.
64
27
657
No requirement on Verifiers?
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.
147
28
Terminology
Should reorder the terms into a logical order - possibly in the order the terms are introduced in the main body. At least the PII lifecycle terms should be together in a sensible order.
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
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.
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201