Disposition of Comments: PICPR20241010

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

Discuss

23

6

113

This wording includes transactions that are not in person at all. Strike "primarily".

Deleted

Changed

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

Changed

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

Changed

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

Changed

68

6

principle’

replace with: "principal"

Replaced

changed

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

Changed

70

7

will be helpful to

replace with: "can be used by"

Replaced

Changed

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

changed

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

Rejected

73

8

etc

See previous comment about lists and "etc"

etc. is used correctly

Rejected

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

changed

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.

rejected

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.

Changed

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.

rejected

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’

accepted

79

8

depend on their Providers

Shouldn't this be "depend on their Vendor"?

changed

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.

Rejected

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.

Changed

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.

changed

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.

changed

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.”

rejected

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.”

rejected

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…

changed

84

10

The figure above

Probably better to say "Figure 2 shows..."

changed

4

11

204

socio-technical, in other places this is one word.

Replaced socio-technical with sociotechnical throughout

changed

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.

rejected

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.

changed

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)

discuss

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.

changed

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.

changed

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?