[WG-InfoSharing] Github Versions Merged

Mark Lizar - OCG m.lizar at openconsentgroup.com
Mon Mar 14 12:29:47 CDT 2016

Answer in line

> On 14 Mar 2016, at 16:59, John Wunderlich <john at wunderlich.ca> wrote:
>> 4. Suggest leaving Consent Type (like Purposes) up to the entity producing it, but provide a base list of choices such as Implied/Implicit,Opt-out, Opt-in, Expressed/Explicit or Not Applicable. So long as the field is not blank, the user is being informed and can make a judgement as to veracity and applicability based on their understanding.
> John, as the specification has always been for explicit consent I see that as out of scope.   Personally   I think this field is redundant.  Also, I think there are many different definitions for what implied consent means.        How would the receipt be judged as to what type of consent it is?   Is this something the implentor would do or the reader?  Even if this was in scope, this adds a lot of   unnecessary complexity to the receipt, there are many different definitions and variations of what is implied,   
> for an implied consent we could get rid of a lot more fields for it to conform to what you have written to be minimum viable. 
> In way of compromise and the spirit of collaboration I  think the Y/N explicit consent flag is very useful.    I am hoping you can meet me half way her. 
> What I’m suggesting is that we leave the definition of consent type up to Bob, recognizing that there are many definitions of valid consent in many jurisdictions. The minimum requirement is to set out that Bob must specify a consent type for the transaction. It’s up to Bob to determine if one of the options provided is appropriate or to put in something specific for his context and language. 

If we leave the definition of what consent is to Bob, then how is Alice going to understand what type of consent it is?  Do we need to make a and define a list of all the types of consent and then Bob and Alice have to conform to these ? 

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

More information about the WG-InfoSharing mailing list