[WG-InfoSharing] Github Versions Merged

John Wunderlich john at wunderlich.ca
Mon Mar 14 14:41:12 CDT 2016


Kind of in the order that they are raised

   1. Valid consent is not always explicit consent. And it’s more
   complicated than a binary explicit/not-explicit.
   2. From my perspective the initial core value of the consent receipt for
   Alice is to enable Bob to tell her what kind of consent he used at or just
   after the actual collection. It’s not up to us (at the MVCR level anyway)
   to try and predetermine what Bob will assert as valid. That can be
   determined by a) Alice, and b) the competent regulator to whom she might
   refer the consent.
   3. The real world is variable and subject to interpretation. If the MVCR
   doesn’t allow that variability for Bob to apply his interpretation,then it
   risks becoming an activist aspiration rather than a practical tool. (See
   Iain’s comments from his SalesForce developers).
   4. Any project changes over time and that includes original scope and
   deliverables statements.
   5. Setting out the information that Bob has to provide Alice is what
   constitutes the standard, whether or not it’s machine readable. In that
   sense I see the MVCR as more like an ISO standard than an IETF
   specification. We’ll get to that kind of specification next (assuming we
   can put the MVCR to bed quickly) with the CR spec which should include a
   semantic element to enable assertion of compliance with different
   regulatory frameworks, like the following notional list.
      1. CR-SelfAsserted => a Consent Receipt that sets out the information
      that the organization attests to meeting the Kantara established minimum
      requirements (to be determined, but I’m thinking maybe ISO 29100?)
      2. CR-TrustMark => a Consent Receipt that sets out the information
      for a third party attestation that the organization is meeting
some [to be
      determined] standard
      3. CR-GDPR => a Consent Receipt that sets out the information
      necessary to demonstrate compliance with the GDPR
      4. CR-PrivacyShield => a Consent Receipt that sets out the
      information necessary to demonstrate compliance with the PrivacyShield


>From my perspective, the MVCR is the first and necessary step along the way
to the above suggested machine readable, interoperable and systemically
usable consents. The MVCR is the version that I can see being
understandable and ’sellable’ to otherwise technology solution resistant
lawyers, marketers or regulators. That was the reason I suggested starting
with a minimum version of the receipt - one that didn’t need any technology
overhead, but that could be used for socializing the consent and empowering
even the least technical of users to create receipts for their users if
they wanted. We’ve never disagreed about the end state, but what the
intermediate minimum version should be.

Sincerely,
John Wunderlich
@PrivacyCDN

Call: +1 (647) 669-4749
eMail: john at wunderlich.ca

On 14 March 2016 at 14:48, Mark Lizar - OCG <m.lizar at openconsentgroup.com>
wrote:

> 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>
> wrote:
>
>
> 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 ?
>
> Mark
>
> _______________________________________________
> WG-InfoSharing mailing list
> WG-InfoSharing at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-infosharing
>
>
>

-- 

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


More information about the WG-InfoSharing mailing list