ISO 27560 ANCR WG Comments Aug 2022

Template for comments and secretariat observations

Date: Aug 8, 2022

Document: ISO/IEC 27560 WD5

MB/ NC1

Line number

Clause/ Subclause

Paragraph/ Figure/ Table/ (e.g. Table 1)

Type of comment

Comments

Proposed change

(e.g. 17)

(e.g. 3.1)

KI/ANCR WG

ge

Every receipt has a dual role as a record of notice and a receipt for  electronic  consent (eConsent). Its role is relative, if kept by the controller it can be called a consent record, in transit or exchange its a receipt, but in the possession of the Principal it is a credential, with a role relative to the credential holder, and the holder's context of use  governed by proceeding notices.  

KI/ANCR WG

1269

Annex E

te

In this WD5 the consent notice record and receipt contains the meta-data of notice, date, time location, as well as the PII Principal Identifier, which contravenes 29100 Sec. 5.11 in addition to international conventions 108+ Art 33 1(a)(b),  GDPR Art 32.1 (a)(b),  to ensure PII is secure and treated properly.   27560 makes an assumption in that the PII Controller -already controls PII and the right to make the consent record is   assumed.   E.g. The JSON record in annex A presents includes the PII Principal identifier, in cleartext along with additional information about the subject (correlatable). For example, the entity to which the identifiers are presented now knows that both identifiers relate to the same subject, as do others with access to the records and receipts.

Remove PII Principal ID from a consent record (e.g. only a receipt or record ID) and / or - provide a section for privacy considerations for this specification, and remove that identifier JSON especially. - add security/privacy consideration - Such a record would itself first require a notice with transparency of over legal justification and must allow the PII Principal to control/access the identifier(s) in the record relating to their PII Principal or other identifiers.

KI/ANCR WG

425 &827 

6.3.3.4

te

The consent receipt v1.1 specification captures a notice event to assess conformance with ISO/IEC 29184 controls.  In 27560 the  event schema is added to the standard to included additional event types out of the scope of notice.    This effects the integrity of the record from the PII Principal's perspective, to include non-notified events, and defeats the purpose of the receipt. 

Reconsider event schema 

KI/ANCR WG

758

6.3.6

te

The term 3rd Party in 27560 references 29100 - and points to the PII Controller Identity.  27560 WD5 contains a party_id schema for digital identification, and in doing so creates a new (additional) stakeholder name and identifier for the PII Controller ID. This extends beyond the 29100 defined privacy stakeholders, and effects the security of the record. It  also appears to create an additional stakeholder type. The PII Controller ID (is the party id) has in addition to Controller role, which should also be provided in a record., the are additional roles, e.g., Processor or Sub-Processor, which can then further defined by function in processing (recipient, holder, issuer, verifier).

Reconsider party schema - Suggest : "All  roles have a PII Controller identity" e.g. processor, principal or 3rd party - which can also be indicated as a recipient"

KI/ANCR WG

451

6.3.4.1

ed

Privacy notice is not the same as  'terms of use' as established in 29184.  Terms of use refer to contract which is  out of scope of consent record, and conflicts with 29184 5.4.5 "clearly differentiated from terms of use"

remove -terms of use 

KI/ANCR WG

1276

Annex E.

1

ed

ISO/TR 23244 points to  ISO/IEC 29100,. If referencing privacy framework for DLT best to use common reference across technologies and use 29100 directly

change to .... considerations can be found in ISO/IEC 29100.