[WG-InfoSharing] Github Versions Merged

Mark Lizar - OCG m.lizar at openconsentgroup.com
Mon Mar 14 13:48:23 CDT 2016


This is my point as well, 
  
If the scope changes from explicit consent to any type of consent  then the specification will loose its value.  Same thing if the back end of the receipt is not specified with data field name and format.  Without the data part of the specification or explict scope it will be implemented with many different names and will have little to no meaning to Alice.  Which IMO make the whole exercise of making a specification redundant. 

Too much variability and interpretation will make the specification meaningless.   This is why explicit consent and systematically usable are the scopes and in this scope each field in there makes sense and comprises the Minimum viable fields.  (except for maybe one or two)  

This is why the compromise of explicit consent y/n is useful, then it can be used for any type of consent. but it still has meaning to indicate that this is complaint with the MVCR for explicit consent.  I think this is then a very valuable specification.     Just sending a signal from bob to alice, that is not  matching readable is much easier and doesn’t need all of the fields that are in there.   In fact, it doesn’t need a specification at all. 

Does anyone else have an opinion?  ? 

Should the scope be explicit consent and machine readable?    

Should it be to just send a signal from bob to alice that consent of some sort has been provided?  

Should we it be something else ?  

I propose  two compromises 

1. that we change consent type to explicit consent Y/N  - this way it can still be systematically usable and it can also be used for any type of consent and still conform to being for explicit consent. 
2. that we have different packages of conformance to asses the MVCR against this makes it easier for different flavours of the MVCR to be developed and it can be flexible in that it scales or devolves to a wider set of use cases. 


Mark 


> On 14 Mar 2016, at 17:43, Iain Henderson <iainhenderson at mac.com> wrote:
> 
> Yes, run MVCR with pick last options I'd suggest.
> 
> That was a significant bit of the feedback when I asked our Salesforce team to deploy. Their point was 'if you don't define it, we'll only have to join the queue to speak to the lawyers, who will bring in their external lawyers, and we'll end up with a watered down version of what you could have put in your pick list I the first place.
> 
> On 14 Mar 2016, at 17:29, Mark Lizar - OCG <m.lizar at openconsentgroup.com <mailto:m.lizar at openconsentgroup.com>> wrote:
> 
>> 
>> Answer in line
>> 
>> 
>> 
>>> On 14 Mar 2016, at 16:59, John Wunderlich <john at wunderlich.ca <mailto: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 ? 
>> 
>> Mark 
>> _______________________________________________
>> WG-InfoSharing mailing list
>> WG-InfoSharing at kantarainitiative.org <mailto:WG-InfoSharing at kantarainitiative.org>
>> http://kantarainitiative.org/mailman/listinfo/wg-infosharing <http://kantarainitiative.org/mailman/listinfo/wg-infosharing>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20160314/9465d66f/attachment-0001.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/9465d66f/attachment-0001.p7s>


More information about the WG-InfoSharing mailing list