Consent timestamp

[ShanChathusanda93]

There is a filed called consentTimestamp in the consent receipt spec. What is the purpose of it? Is it the time that an organization get the user consent? or is that the time that the organization creates a consent receipt?

Thanks.

[smartopian]

These questions are good and I am collecting for guidance. - That is the time the user gets the consent

…

On 7 Nov 2017, at 11:41, Shan Chathusanda Jayathilaka ***@***.***> wrote: There is a filed called consentTimestamp in the consent receipt spec. What is the purpose of it? Is it the time that an organization get the user consent? or is that the time that the organization creates a consent receipt? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#116>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGPq569-Axlz5W_AeZ_hrxQ82yGQrLFSks5s0EHwgaJpZM4QUqK6>.

[dturnerx]

From section 3 - Terms and Definitions
3.5. Consent Timestamp
The time and date when consent was obtained from the PII Principal.

[ShanChathusanda93]

Hi @smartopian and @dturnerx
I have another scenario. If an user gives his/her consent in two different times (to the same data controller), then what time is the consentTimestamp?

[Pushpalanka]

As per my understanding consent receipt represents the consents given by a single PII Principal on many services and many purposes. Apart from what Shan pointed out, same PII principal might have given consent for different purposes at different times.

Eg: PII principal gives consent use contact details for authentication services at the very beginning. Then after couple of months gives consent to use contact details for promotional activities.

In such case what should be the consent timestamp of the receipt? As this can differ from service to service and purpose to purpose, we need some logic to decide the timestamp I guess.

Doesn't it make sense to put the consent generation timestamp here, as it indicates the time when the consent receipt was generated. So it means as of this moment of time, these are consents relevant to a PII principal. This make it precise as later PII principal might have modified the consent details too.

Appreciate your thoughts..

[dturnerx]

Every consent transaction should produce a new CR. So, if a user provides consent at two different times the PII Controller must produce two CRs and each one will have its own consent timestamp (whether or not the services & purposes are different.)

If you look at an extreme edge-case where a PII Principal is being asked to reaffirm their consent for the same conditions, then it may be the case that the only difference between the new CR and the original CR is the consent timestamp.

I understand this does not address the issue of when the CR was created and I agree it's worth adding to the list of future enhancement. In the meantime, nothing prevents a PII Controller from adding that information to their implementation and including it as a custom JSON field.

[dturnerx]

@ShanChathusanda93 & @Pushpalanka
Every consent transaction should produce a new CR. So, if a user provides consent at two different times the PII Controller must produce two CRs, and each one will have a distinct consent timestamp (whether or not the services & purposes are different.)

If you look at an extreme edge-case where a PII Principal is being asked to reaffirm their consent for the same conditions, then it may be the case that the only difference between the new CR and the original CR is the consent timestamp.

I understand this does not address the issue of when the CR was created, and I agree it's worth adding to the list of future enhancement. In the meantime, nothing prevents a PII Controller from adding that information to their implementation and including it as a custom JSON field.

[ShanChathusanda93]

Hi @dturnerx,
Q1. As your reply, you are telling that if the user provides consent in two times the data controller must create two CRs to that same user. In my suggestion, can't we add this consent timestamp as a purpose property in the CR. So in that case the data controller no need to create separate CRs to one user. DC can create only one CR for one user.

Q2. Is it ok to customize the CR scheme to enter the consent timestamp as a purpose property?

Regards,

[ShanChathusanda93]

Hi @dturnerx
Kind reminder of the above issue.

Thanks and regards.

[dturnerx]

@ShanChathusanda93
Q1. The short answer is yes, you could build a solution like that, although this creates a different problem. In the ideal case, a CR should not be changeable after it has been produced and sent to the user, which is usually done by signing the CR. This means any changes you make to the original CR will invalidate the signature.

Q2. Yes, because of differences in jurisdictional, regulatory, and industry requirements there will need to be more variations than a single spec can accommodate. Therefore, some implementations will need to extend the base CR to suit their requirements, which we anticipated from the beginning.

[ShanChathusanda93]

Hi @dturnerx,
Sorry for the late reply. In Q1 you told that consent receipt can't be changeable. Think this kind of scenario. If an user gives consent to three purposes at one day. User also requesting and getting a CR. Then the user removes consents for two purposes. Then again user requesting a CR. Then we have to create another CR with the current consents. So the CRs are different in two times. Please feel free to provide a feedback for this.

In Q2 you told that we can put consentTimestamp as a custom JSON field in CR. So when an user uploading the JSON to give the consent to another org, will there be no errors bcoz of that custom field.

Thanks.

[PrivacyCDN]

Shan; A Consent Receipt is a point in time record of a transaction and is accurate as of the time of issuance. If, five minutes after Alice consents to sharing for marketing purposes she elects to change that consent to deny, then a new consent receipt for that transaction should be issued. The value of having an artefact is that when each party keeps copies of their receipts, then neither can claim an out of date or otherwise inaccurate receipt as the most current record. Further, I think that there is a good case to be made under GDPR that a change in the underlying privacy policy could require a new consent, or at least the issuance of a new Consent Receipt to both memorialize the change and notify the data subject of the change. John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

…

_____________________________ From: Shan Chathusanda Jayathilaka <[email protected]> Sent: Tuesday, December 19, 2017 4:52 AM Subject: Re: [KantaraInitiative/CISWG] Consent timestamp (#116) To: KantaraInitiative/CISWG <[email protected]> Cc: Subscribed <[email protected]> Hi @dturnerx<https://github.com/dturnerx>, Sorry for the late reply. In Q1 you told that consent receipt can't be changeable. Think this kind of scenario. If an user gives consent to three purposes at one day. User also requesting and getting a CR. Then the user removes consents for two purposes. Then again user requesting a CR. Then we have to create another CR with the current consents. So the CRs are different in two times. Please feel free to provide a feedback for this. Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#116 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADTJ9t_VgoWdhn4VmM5FAyPQEfoRNDdbks5tB4dUgaJpZM4QUqK6>.

-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

[smartopian]

A simple solution might be to
--1. specify timestamp for the interaction and record to GMT 0 -

2. As for timestamp per purpose - that should be covered by the per interaction logic in step 1.

(does this address the issues? )