/
Disposition of Comments: PICPR20241010

Disposition of Comments: PICPR20241010

Document or Set Title: Recommendations for Privacy Enhancing Mobile Credentials v.1

Document Status: Group Approved Draft Recommendation

Originating Work Group: Privacy Enhancing Mobile Credentials (PEMC)

Comment Review Period Closing Dates: October 10 - November 23, 2024

Submitted to Leadership Council: pending comment period

Leadership Council Comments: N/A

Comment form for multiple comments:

Ref #

Page#

Line #

Comment Type: Editorial or Technical

Comment / Request

Proposed Edit / Change

Status

Discuss

Changed

Rejected

WG Accepted

WG Rejected

Ref #

Page#

Line #

Comment Type: Editorial or Technical

Comment / Request

Proposed Edit / Change

Status

Discuss

Changed

Rejected

WG Accepted

WG Rejected

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.