[WG-InfoSharing] Issue Purpose & PI Category List Re: Urgent Issue List & a bit of back ground on Consent Type.

Mark mark at smartspecies.com
Tue Nov 22 05:41:57 CST 2016


Thanks Eve,

This is a great pattern for us to work on.


> On 25 Oct 2016, at 18:28, Eve Maler <eve at xmlgrrl.com> wrote:
> 
> It turns out UMA basically uses one design pattern, not really multiple:
> 
> pat_profiles_supported (etc.) in config data (Core Sec 1.4 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#am-endpoints>): A URI (as a string alternative) appears here as a signal that the server supports a particular OAuth grant flow or token type. I think this is a good analog for CR purpose semantics, because the OAuth spec defines native stuff with plain strings and advises others to define extensions and give them URI identifiers. So (string or URI) covers the universe of identifier possibilities in UMA's case.
> 
> name, claim_type, and claim_token_format (Core Sec 3.5.4.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#authorization-failure>) in required_claims: Claim semantics: Same mechanism as above. The string MAY be a URI, and the URI represents someone else's attempt to standardize semantics that UMA has no part of.
> 
> (There are a couple more instances...)
> 
> 
> Eve Maler
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> 
> 
> On Tue, Oct 25, 2016 at 6:43 AM, Mark OCG <m.lizar at openconsentgroup.com <mailto:m.lizar at openconsentgroup.com>> wrote:
> Hi Eve,
> 
> This is really a good idea - there are a number of existing notions around how to list purpose(s).  An original assumption has been to link directly to a purpose or just link to privacy policy (not very user friendly) - I think linking to a purpose URI is even better !!  (do you have an example of a URI mapping?)
> 
> The other consideration, when specifying how to list purpose,  is how to display and format purpose(s) enabling consistency.
> 
> - Mark
> 
> 
>> On 23 Oct 2016, at 16:08, Eve Maler <eve at xmlgrrl.com <mailto:eve at xmlgrrl.com>> wrote:
>> 
>> I'm not a subject matter expert here, but Iain's suggestion sounds kind of close to what is often done in specs when you need an extensibility point because there are other orthogonal standards worlds and communities out there:
>> 
>> Wherever a purpose needs to be supplied, one option is to supply a purpose URI, and your spec can define a mechanism for mapping such a URI to its definition, and if you feel it's necessary, you can even define an IANA registry for such mappings as they relate to your spec.
>> 
>> Let's say HIPAA defines "treatment, payment, and operations" (TPO) formally as a purpose. It would be possible through this method for some CR user to ensure they mean this definition when the URI is supplied. You could even give an example like this in the V1 spec, likely without actually doing any of the work of any real mappings at all and leaving it up to third-party communities.
>> 
>> (UMA has some instances of this mechanism in heavier and lighter weights.)
>> 
>> FWIW...
>> 
>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 <tel:%2B1%20425%20345%206756>
>> 
>> On Oct 23, 2016, at 12:14 AM, Iain Henderson <iainhenderson at mac.com <mailto:iainhenderson at mac.com>> wrote:
>> 
>>> As regards the purpose, I think the optimal approach would to to do as discussed several months back - put up a solid URL with a well thought through and explained list of purposes that can be dropped into receipts, but also ensure the spec allows the data controller to list multiple 'other' purposes of their own. That allows us to close some big holes, without being overly or unrealistically proscriptive.
>>> 
>>> Same applies to data type list.
>>> 
>>> Iain
>>> 
>>> On 22 Oct 2016, at 17:29, Mark <mark at smartspecies.com <mailto:mark at smartspecies.com>> wrote:
>>> 
>>>> 
>>>> I think the action item of bringing up remaining items for discussing by the WG on the list and inviting others to engage on them has been achieved.
>>>> 
>>>> Hopefully this inspires quality discourse.   David, please let us know if there are any other items that need to be discussed.
>>>> 
>>>> All - Good luck at IIW next week
>>>> 
>>>> - Mark
>>>> 
>>>> 
>>>>> On 22 Oct 2016, at 15:33, John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>> wrote:
>>>>> 
>>>>> +1
>>>>> 
>>>>> Thanks, John
>>>>> 4giv spellin errurz from mobile devize
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Oct 22, 2016 at 10:07 AM -0400, "Andrew Hughes" <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>> wrote:
>>>>> 
>>>>> Thanks for the clarification.
>>>>> 
>>>>> So please stop trying to argue it out. Stay focused on 1 and 2 and park all the #3 topics for later. It keeps coming back because everyone keeps it going in threads! :)
>>>>> 
>>>>> Or please fork the threads to keep the issues distinct.
>>>>> 
>>>>> Andrew.
>>>>> On Sat, Oct 22, 2016 at 7:02 AM John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>> wrote:
>>>>> Andrew;
>>>>> 
>>>>> I think it is the case that the first two areas in your list are related in that no one wants to create a 1.0 spec that will not be adopted. So discussions about uptake and likely reception are related to what the WG wants in v1.0. That being said, my basic motivation to delete "Purpose Specification" is to get to v1.0.
>>>>> 
>>>>> As to the third item, state of practice, I believe I agree that it doesn't belong as part of the discussion, but it keeps getting brought in.
>>>>> 
>>>>> Thanks, John
>>>>> 4giv spellin errurz from mobile devize
>>>>> 
>>>>> _____________________________
>>>>> From: Andrew Hughes <andrewhughes3000 at gmail.com <mailto:andrewhughes3000 at gmail.com>>
>>>>> Sent: Saturday, October 22, 2016 9:52 AM
>>>>> Subject: Re: [WG-InfoSharing] Issue Purpose & PI Category List Re: Urgent Issue List & a bit of back ground on Consent Type.
>>>>> To: Mark Lizar <mark at smartspecies.com <mailto:mark at smartspecies.com>>, John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>>
>>>>> Cc: <wg-infosharing at kantarainitiative.org <mailto:wg-infosharing at kantarainitiative.org>>
>>>>> 
>>>>> 
>>>>> 
>>>>> John and mark: you are each discussing different topics as if they are the same one. Good information, but please be careful to avoid talking past each other too much.
>>>>> - what needs to be done to get to v1.0
>>>>> - what needs to be done for adoption, uptake by implementors
>>>>> - what needs to be done to advance the state of practice for the benefit of people
>>>>> 
>>>>> Andrew.
>>>>> On Sat, Oct 22, 2016 at 6:34 AM John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>> wrote:
>>>>> Mark;
>>>>> 
>>>>> It’s not a tough issue. We have two fields that will contain overlapping or duplicate information: “Purposes” and “Purposes Specification” That’s bad design and one needs to go. Let’s keep the one that refers to list of purposes, provide a candidate list of purposes, and move on.
>>>>> 
>>>>> It’s not the job of the specification to proscriptively fill the space left by regulations that say ‘collect data only for specified purposes’ but do NOT provide lists or guidance on what those purposes might be. First, there are good reasons why the regulations are written that way, not least of which is to allow for innovation, choice and competition. It is also not the job of the spec to fill a ‘big hole in consent law’. Parenthetically, I would ask if you mean instead, “Deficiencies in the consent provisions of privacy law”? The job of the spec with respect to purpose, as I see it, is to provide a vehicle for the PII controller to identify the purposes they are claiming and communicate them to the PII subject after consent and collection. Any subsequent use or disclosure of PII will then have to be able to be shown to be in fulfillment of one or more of those purposes.
>>>>> 
>>>>> In the larger context I would argue that consent regulations plus a non proscriptive consent receipt will provide a tool to enable implementors to iterate and experiment to determine what reasonable consent and specified purposes actually mean in the context of the jurisdictions and data subjects that are specific to them. Does that mean that bad actors could use the consent receipt to try “We have collected your information and have your consent to do anything we damn well please with it”? Yes, but it also allows good actors to explicitly compete with that. If we try and proscribe what purposes can be included in a receipt, we risk losing the consent receipt as a general purpose tool useful for both Alice and Bob and have it become a tool of advocacy and unlikely for mass adoption.
>>>>> 
>>>>> JW
>>>>> 
>>>>> 
>>>>> Sincerely,
>>>>> John Wunderlich
>>>>> @PrivacyCDN <https://twitter.com/PrivacyCDN>
>>>>> 
>>>>> Call: +1 (647) 669-4749 <tel:%2B1%20%28647%29%20669-4749>
>>>>> eMail: john at wunderlich.ca <mailto:john at wunderlich.ca>
>>>>> 
>>>>> On 22 October 2016 at 07:42, Mark Lizar <mark at smartspecies.com <mailto:mark at smartspecies.com>> wrote:
>>>>> There are reasons why this issue has been left to last
>>>>> 
>>>>> 1. the integrity of the spec will come down to how this specific issue is dealt with, in some ways there is a lot at stake
>>>>> 2. we collectively need to have a better understanding of the specification, and its role to try and sort this problem out
>>>>> 3. Its a bloody tough issue
>>>>> 
>>>>> Although, there is more to this issue, more than what is already in this thread.  The laws say that purpose specification must be lawful. In industries and jurisdictions for sensitive personal data there is an additional level of legal requirements for notice to make consent lawful.
>>>>> 
>>>>> In many ways John, I applaud you taking such a good stab it, and I think we can go with your recommendation.   But, to not understand this particular issue and the potential of focusing on its as a group.
>>>>> 
>>>>> Purpose Specification is the big hole in consent law - like Iain says.  So - my recommendation - is if we want people to have meaningful consent we need to do better.   We need to start with an approach and iterate on it.  Personally I think this issue represents the ability for people to withdraw consent and make a choice, and without meaningful purpose specification that is scalable systemically. I am not sure how that will happen.  So, if  anyone has any ideas about how to move this forward - please don’t be shy.
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Mark
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 21 Oct 2016, at 22:10, Mark <mark at smartspecies.com <mailto:mark at smartspecies.com>> wrote:
>>>>> 
>>>>> Hi John,
>>>>> 
>>>>> Interesting recommendation - but still not quite clear.
>>>>> 
>>>>> On 21 Oct 2016, at 19:44, John Wunderlich <john at wunderlich.ca <mailto:john at wunderlich.ca>> wrote:
>>>>> 
>>>>> All this to say that I recommend
>>>>> 
>>>>> 1. We delete the "Purpose Specification" Field ​from the specification
>>>>> 
>>>>> Do you mean delete the purpose category field? Purpose specification I thought was just a practice or process of how to specify a purpose (or something like that).
>>>>> 
>>>>> the idea behind purpose category - is that this would then provide a common purpose type  - so that it can be used more systemically - perhaps not always required, but much easier to fit on a receipt, easier to implement, and digest/understand. The original thinking there was that this would then link to a purpose description in a policy, or could be a drop down. Nothing definitive has ever been discussed.
>>>>> 
>>>>> 2. We identify the "Purposes" field as a list of 1 or more purposes identified by the PII controller
>>>>> 
>>>>> Ok - not a bad option - what guidance would you give - for explaining how to define or format the the purpose description field ?  is this a sentence, a paragraph?  should this be listed on the receipt its self?  would this be different if it was a mobile device?
>>>>> 
>>>>> 3. We add an appendix to the Specification, similar to Appendix A (PII Categories), which will contain a list of purposes that an implementor MAY, but is not required, to chose from to included in the list of purposes.
>>>>> 
>>>>> when trying to implement this is where I ran into the most difficulty - three did not seem to be a common list of purposes and this seemed in lots of cases to be context specific.
>>>>> 
>>>>> The aim with purpose categories was to get this into a more systematically usable framework - as well - there are multiple indications that data retention periods for purposes come from a purpose category.  Another potential benefit.
>>>>> 
>>>>> 
>>>>> 
>>>>> With respect to 3, I'll defer to David whether that should be in the spec as an appendix or as a separate guidance documents.
>>>>>>>>>> 
>>>>> _______________________________________________
>>>>> 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>
>>>>> 
>>>>> 
>>>>> 
>>>>> 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.
>>>>> _______________________________________________
>>>>> 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>
>>>>> --
>>>>> Andrew Hughes CISM CISSP
>>>>> Independent Consultant
>>>>> In Turn Information Management Consulting
>>>>> 
>>>>> o  +1 650.209.7542 <tel:%2B1%20650.209.7542>
>>>>> m +1 250.888.9474 <tel:%2B1%20250.888.9474>
>>>>> 1249 Palmer Road,
>>>>> Victoria, BC V8P 2H8
>>>>>  <>AndrewHughes3000 at gmail.com <mailto:AndrewHughes3000 at gmail.com>
>>>>>  <>ca.linkedin.com/pub/andrew-hughes/a/58/682/ <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/>
>>>>> Identity Management | IT Governance | Information Security
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 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.
>>>>> --
>>>>> Andrew Hughes CISM CISSP
>>>>> Independent Consultant
>>>>> In Turn Information Management Consulting
>>>>> 
>>>>> o  +1 650.209.7542 <tel:%2B1%20650.209.7542>
>>>>> m +1 250.888.9474 <tel:%2B1%20250.888.9474>
>>>>> 1249 Palmer Road,
>>>>> Victoria, BC V8P 2H8
>>>>> AndrewHughes3000 at gmail.com <>
>>>>> ca.linkedin.com/pub/andrew-hughes/a/58/682/ <>
>>>>> Identity Management | IT Governance | Information Security
>>>>> 
>>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> 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>
>>> _______________________________________________
>>> 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>
>> _______________________________________________
>> 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>
> 
> 
> _______________________________________________
> WG-InfoSharing mailing list
> WG-InfoSharing at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-infosharing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20161122/75140c5f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://kantarainitiative.org/pipermail/wg-infosharing/attachments/20161122/75140c5f/attachment-0001.sig>


More information about the WG-InfoSharing mailing list