[WG-InfoSharing] Security Considerations for the Consent Receipt

Salvatore D'Agostino sal at idmachines.com
Tue Oct 3 21:05:12 UTC 2017


On the PII front, I guess the thought is that you might have a receipt w/only  an identifier, hash of one, one on a ledger, and that there isn’t necessarily PII involved in that case.  The issuer’s signature, if all their receipts are the same need not include PII.  Edge case and possibly a distraction but in came up in conversation so given it was a draft it was included for comment.

 

 

From: Tom Jones [mailto:thomasclinganjones at gmail.com] 
Sent: Tuesday, October 3, 2017 4:32 PM
To: Mark Lizar <mark at openconsent.com>
Cc: wg-infosharing at kantarainitiative.org; Salvatore D'Agostino <sal at idmachines.com>
Subject: Re: Security Considerations for the Consent Receipt

 

Not clear about pii.

If the provider gives the user a list of the fields that it requires for processing, is that not a valid consent receipt?

More to the point, is "the user requesting and receiving a consent receipt" not pii?

If the receipt is from a HIV/AIDS clinic, I would think it was.

..tom




Peace ..tom

 

On Tue, Oct 3, 2017 at 7:58 AM, Mark Lizar <mark at openconsent.com <mailto:mark at openconsent.com> > wrote:

 

H Everyone, 

 

Sal & I had a chat about the first draft of security considerations - Sal mentioned that Tom Jones (cc'd) reached out and raised some very good points for security considerations. 

 

In this regard, we have started a draft outline of Security Considerations. 

 

We agreed and you’ll see these Security Considerations are explicit about being only for the consent receipt and not for any other type of personal data receipt - or any other kind of personal information management use cases.  

 

** Security Considerations *** 

 

General - Since consent receipts can contain personal information it is a requirement that transmission of consent receipts not take place in the clear and that secure communications, i.e. HTTPS (properly implemented) be used.  The requirements for implementers of consent receipts and consent management include, signing, encryption, key management and other operations for their creation, transmission, use and storage, if the consent receipt is to be useful for proof of consent, withdrawal of consent or any other rights.

 

1.	Securely authenticated connection - use modern cryptology
2.	If receipt contains PII, a receipt without PII is not in scope here, but possible - and it needs to be transmitted, using the secure connection in 1, at the point of consent the user must be able to manage the receipt interactions with:

1.	Local machine (server, client, application, device..) 

1.	Use and storage needs further considerations

2.	Other receipt repositories and consent services

1.	Security of these repositories and services - i.e. non-local - requires considerations but is currently out of scope of the CR v1.1 spec 

1.	When considered it should include the use case where for some reason a receipt has not been transmitted it should be available from the provider of the receipt repository for direct download. This and other infrastructure is out of scope for the Consent Receipt discussion.

3.	Transmission of the receipt - with personal information is considered here 

1.	A receipt without PII is not in scope at this time

3.	The ability to validate and revoke the receipt – and other aspects of the consent receipt lifecycle is out of scope at this time for the consent receipt specification but will need to be taken up shortly.

1.	Perhaps this is a topic for the Consent Best Practices? 
2.	If so, these  consideration should include 

1.	Status and revocation of consent 
2.	Consent management & validation; to include other aspects of its lifecycle  

 

 Hopefully this is a good starting point for others on this list to jump in.

Best,  

Mark Lizar

CEO & Founder | Open Consent | 

Trust is the new currency and its measured in the quality of Consent 

+44 (0) 208 123 2476 <tel:+44%2020%208123%202476> 

Twitter @Smartopian

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20171003/2422b878/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4823 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20171003/2422b878/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list