The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized. A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR. Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that. It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com> wrote:

Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www. commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/ eur-lex/GDPR/Comment/Consent/0.md

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/ gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/ eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

http://kantarainitiative.org/confluence/display/uma/UMA+lega l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 2016-09-02

- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> - Eve will try to press ahead with lots of editing AIs prior to the call - Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review

Attending: Eve, Kathleen, Ann, John W, Mary, Jim

We did a ton of work in the document.

If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. Please feel free to share it.

See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> .

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree. Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md ) Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy. The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes. On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:

Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper <agropper@healthurl.com> wrote:

...

The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized.

A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR.

Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.

It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian

On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonacco rd.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/ Comment/Consent/0.md

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/go v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu /europa/eur-lex/GDPR/Form/0.md#Article.Sec

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

http://kantarainitiative.org/confluence/display/uma/UMA+lega l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 2016-09-02

- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> - Eve will try to press ahead with lots of editing AIs prior to the call - Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review

Attending: Eve, Kathleen, Ann, John W, Mary, Jim

We did a ton of work in the document.

If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. Please feel free to share it.

See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> .

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

Nobody ever said that you were critical about CommonAccord. The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify. I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways. Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra. Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well. You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly. What do you say? Charter up and get going? Andrew. Kantara Initiative Leadership Council Chair *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security * On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com> wrote:

My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/ 2016/08/29/onc-announces-blockchain-challenge-winners.html (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source& file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act- of-2015/Policy/Acme_Privacy_Policy.01.md )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

...

Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper <agropper@healthurl.com> wrote:

...

The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized.

A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR.

Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.

It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian

On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonacco rd.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/ Comment/Consent/0.md

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/go v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu /europa/eur-lex/GDPR/Form/0.md#Article.Sec

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote:

...

http://kantarainitiative.org/confluence/display/uma/UMA+lega l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 2016-09-02

- Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> - Eve will try to press ahead with lots of editing AIs prior to the call - Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review

Attending: Eve, Kathleen, Ann, John W, Mary, Jim

We did a ton of work in the document.

If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. Please feel free to share it.

See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> .

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections. Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation. There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves). My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale. In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power. In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:

Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com> wrote:

...

My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/ 2016/08/29/onc-announces-blockchain-challenge-winners.html (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source&f ile=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of- 2015/Policy/Acme_Privacy_Policy.01.md )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

...

Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper <agropper@healthurl.com> wrote:

...

The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized.

A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR.

Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.

It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian

On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com

...

wrote:

...

Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonacco rd.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/ Comment/Consent/0.md

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/go v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu /europa/eur-lex/GDPR/Form/0.md#Article.Sec

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote:

> http://kantarainitiative.org/confluence/display/uma/UMA+lega > l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 > 2016-09-02 > > - Working session on User-Managed Access (UMA) in Contractual > and Regulatory Contexts > <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> > - Eve will try to press ahead with lots of editing AIs prior > to the call > - Adrian and Kathleen have sent various suggestions in > list/private email in the last month we should review > > Attending: Eve, Kathleen, Ann, John W, Mary, Jim > > We did a ton of work in the document. > > If you haven't seen it, the latest version of the slides with the > "legal use cases" is here > <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. > Please feel free to share it. > > See also Jim's CommonAccord capture of the GDPR > <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> > . > > > *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > > > _______________________________________________ > WG-UMA mailing list > WG-UMA@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > >

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

-- @commonaccord

This is great James, thanks. - M

On 4 Sep 2016, at 00:28, James Hazard <james.g.hazard@gmail.com> wrote:

Skeleton of a Privacy Policy derived from the GDPR: http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md <http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md>

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote: It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections.

Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.

There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves).

My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale.

In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.

In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md <http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md>

On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes <andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com>> wrote: Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

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@gmail.com <mailto:AndrewHughes3000@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

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-... <http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-winners.html> (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote: Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy.http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md <http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md> )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes <andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com>> wrote: Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

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@gmail.com <mailto:AndrewHughes3000@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

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized.

A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR.

Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.

It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian

On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote: Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md>

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ <http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/>

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec>

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02> 2016-09-02 Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> Eve will try to press ahead with lots of editing AIs prior to the call Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review Attending: Eve, Kathleen, Ann, John W, Mary, Jim We did a ton of work in the document. If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. Please feel free to share it. See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec>.

Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>

-- @commonaccord

-- @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

Start a discussion group to figure out how to do this. On Sat, Sep 3, 2016 at 8:26 PM Adrian Gropper <agropper@healthurl.com> wrote:

I agree with John's explanation of regulatory capture. The way to address it is unclear to me. It's not a standards problem. It's probably a culture problem.

Let's assume we want companies to compete on privacy the way they compete on cost or convenience. A company would then have to be able distinguish itself by highlighting specific privacy features that their competitor does not offer. They would use bold bullet points for privacy the way others do for price, acceleration, or mileage.

imagine two companies selling ride-sharing services, say, Uber and Lyft, with access to all sorts of personal info including phone, locations, credit card, and some social network components. How would one of these companies use Jim's Skeleton of a Privacy Policy below to differentiate themselves?

Adrian

On Saturday, September 3, 2016, Mark OCG <m.lizar@openconsentgroup.com> wrote:

...

This is great James, thanks.

- M

On 4 Sep 2016, at 00:28, James Hazard <james.g.hazard@gmail.com> wrote:

Skeleton of a Privacy Policy derived from the GDPR:

http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections.

Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.

There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves).

My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale.

In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.

In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR -

http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md

On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

...

Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com> wrote:

...

My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-... (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard < james.g.hazard@gmail.com> wrote:

...

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

> Well, given that GDPR is pan-EU and takes effect soon and has real > financial penalties, I'd say that it's not a bad place to start. > > Rather than dismissing other's proposals, what do you propose > instead? > > I'd love to see what you've got in mind to take the 10 pages down to > the short versions. Also preferably text that works for non-US regulations. > > andrew. > > > > *Andrew Hughes *CISM CISSP > Independent Consultant > *In Turn Information Management Consulting* > > o +1 650.209.7542 > m +1 250.888.9474 > 1249 Palmer Road, > Victoria, BC V8P 2H8 > AndrewHughes3000@gmail.com > ca.linkedin.com/pub/andrew-hughes/a/58/682/ > *Identity Management | IT Governance | Information Security * > > On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper < > agropper@healthurl.com> wrote: > >> The GDPR is useful but not enough. We need to see more companies >> compete on the basis of privacy the way they compete on cost or features. >> To enable that, we need privacy policies that are structured and >> standardized. >> >> A standards-type of organization would need to categorize the >> various kinds of information business and then write a standard privacy >> policy for that category. Businesses would be asked to self-assert a >> category and only list the exceptions for their business relative to the >> standard. Categories could be for banks, telecom, merchants, social media, >> multi-player games, health services, media distribution, government >> services, productivity software, home appliances, and a handful more. It's >> pretty easy to tell which category any given product or service is in terms >> of personal information handling as defined in the GDPR. >> >> Within the categories, we would pull out and structure obvious >> features such as: is a standard API available for 100% of the private >> information they hold (like a calendar or email service do); how does the >> business provide transaction notification to users; prior notification of >> policy changes; does the business ever export de-identified individual >> level data; which national jurisdiction is data processed under; is there a >> right to immediate export and deletion including backups, what technologies >> are used to track users; and a few more like that. >> >> It would not take much to move from the 10-page privacy policies >> and terms of use we have today to a typical policy having 0 to 6 exceptions >> on a single mobile phone screen. >> >> From my perspective as a privacy advocate, simply working toward >> model clauses or applying CommonAccord to GDPR would be helpful but it >> could also be a distraction at a time when we need to make very rapid >> progress to avoid a crisis. Do we really believe that GDPR and HIPAA are >> the future or are they just the camel's nose under a very shaky tent? >> >> Adrian >> >> On Fri, Sep 2, 2016 at 8:05 PM, James Hazard < >> james.g.hazard@gmail.com> wrote: >> >>> Great work! >>> >>> As we considered "consent" vs other words in the conversation >>> today, the GDPR's vocabulary seemed important, because it is likely to have >>> great influence on privacy, in Europe and outside. >>> http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md >>> >>> A thought occurred to me - what if privacy policies and similar >>> agreements relating to privacy mapped to the organization of provisions of >>> the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. >>> This would provide a base for a common taxonomy. The taxonomy would prove >>> inadequate or undesirable, at least in detail, in many circumstances, but >>> it is an influential starting place. >>> >>> Some time ago, I played with this notion in connection with the >>> CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the >>> CPBR calls for organizations (like Kantara?) to create charters that can be >>> used by companies. I played out the idea as a privacy policy that >>> referenced a charter, which in turn mapped to (was mostly made from) the >>> CPBR. The resulting privacy policy is goofy, but it demonstrates a >>> chain-of-text that connects all the layers of the conversation. >>> >>> >>> http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ >>> >>> The GDPR has the additional advantage of being quite complete, >>> actually enacted, available in many languages, etc. >>> >>> http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec >>> >>> On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote: >>> >>>> >>>> http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... >>>> 2016-09-02 >>>> >>>> - Working session on User-Managed Access (UMA) in Contractual >>>> and Regulatory Contexts >>>> <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> >>>> - Eve will try to press ahead with lots of editing AIs >>>> prior to the call >>>> - Adrian and Kathleen have sent various suggestions in >>>> list/private email in the last month we should review >>>> >>>> Attending: Eve, Kathleen, Ann, John W, Mary, Jim >>>> >>>> We did a ton of work in the document. >>>> >>>> If you haven't seen it, the latest version of the slides with the >>>> "legal use cases" is here >>>> <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. >>>> Please feel free to share it. >>>> >>>> See also Jim's CommonAccord capture of the GDPR >>>> <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> >>>> . >>>> >>>> >>>> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: >>>> @xmlgrrl >>>> >>>> >>>> _______________________________________________ >>>> WG-UMA mailing list >>>> WG-UMA@kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>> >>>> >>> >>> >>> -- >>> @commonaccord >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! >> HELP us fight for the right to control personal health data. >> DONATE: http://patientprivacyrights.org/donate-2/ >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA@kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> >

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

-- @commonaccord

-- @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

John- Thank you for the thoughtful distinction between the role of standards groups like Kantara and advocacy groups like PPR in regulatory capture. PPR has spent much energy in analyzing privacy policies as a result of work we've done to develop and apply our Framework. I spend pretty much all of my time analyzing the privacy impact of standards. These two activities of PPR parallel the two sides of regulatory capture - political and technical - to oversimplify your analysis. Which brings us back to CommonAccord and related efforts to structure privacy policies that typically are designed to protect the asymmetry that advocates might try to reduce. Wouldn't the introduction of CommonAccord make PPR's job much easier? For example, a paper like the recent one from EPFL (attached), shows how hard it can be to reduce privacy practices to a useful feature description. The introduction of CommonAccord would make that analysis easier to the extent that GDPR is well designed and forces a clear link between privacy practices and privacy policies - as your comment teaches. The application of CommonAccord to GDPR could transform the landscape for regulatory capture if CommonAccord is voluntarily adopted by industry in writing their policies or even if a new generation of academics like Prof. Sweeny's or EPFL decides to use natural language processing to map privacy policies into CommonAccord after the fact. I'm not sure what all this says about the standards work of Kantara and others. UMA-legal, for example, might double down on focusing on GDPR and CommonAccord before looking at the more general problem. That would be interesting. Adrian On Sun, Sep 4, 2016 at 7:46 AM, John Wunderlich <john@wunderlich.ca> wrote:

Adrian;

Regulatory capture is usually dealt with politically rather than culturally. Witness the activism around net neutrality - there appeared to be real risks of regulatory capture there.

WRT to Uber/Lyft competing on privacy I'd say the following:

1. THe privacy notice published serves as a warranty to protect corporate risk. These documents aren't and shouldn't be expected to serve a primary purpose of protecting customer privacy. 2. If a company wants to compete on privacy it will do it by A) designing and producing products and services with privacy in mind (Privacy by Design if you will) B) Including privacy in marketing and product/service documentation C) Making sure that the privacy notice (public) and the privacy policy (internal) align with the privacy goals. By claiming privacy in marketing, then managing corporate risk will require appropriate updates to the privacy notice 3. In a duopoly or network dominated market, competition is usually not a primary determinant of corporate behaviour. Competition requires a market that is not so clearly dominated by 1 or a few significant players. If a privacy related technology were a disruptive technology it might change the market, and maybe there is a VRM related technology that can serve that role (ahem, JLINC data provenance for example). 4. Change in these market requires regulatory intervention or some other external pressure (like Patient Privacy Rights in health, EFF, EPIC, CDT, Privacy International and so on). As breach publicity rises and as the cost of violating privacy (class action law suits, new and expensive privacy rules and regultarions then (to point 1) managing corporate privacy risks will have to address these concerns.

In other words, business/technical initiatives like VRM and/or Kantara can develop and provide the tools or innovations to enable the possibility of increased patient/customer autonomy. This creates the the potential to address the power imbalance between Alice and EvilBobCo but without public awareness and pressure to help develop market demand and make regulatory allowances, it will be a much harder row to hoe.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: Adrian Gropper <agropper@healthurl.com> Sent: Saturday, September 3, 2016 11:26 PM Subject: Re: [WG-UMA] Notes from UMA legal telecon 2016-09-02 To: Mark OCG <m.lizar@openconsentgroup.com> Cc: Deborah Peel <dpeelmd@patientprivacyrights.org>, wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org>

I agree with John's explanation of regulatory capture. The way to address it is unclear to me. It's not a standards problem. It's probably a culture problem.

Let's assume we want companies to compete on privacy the way they compete on cost or convenience. A company would then have to be able distinguish itself by highlighting specific privacy features that their competitor does not offer. They would use bold bullet points for privacy the way others do for price, acceleration, or mileage.

imagine two companies selling ride-sharing services, say, Uber and Lyft, with access to all sorts of personal info including phone, locations, credit card, and some social network components. How would one of these companies use Jim's Skeleton of a Privacy Policy below to differentiate themselves?

Adrian

On Saturday, September 3, 2016, Mark OCG <m.lizar@openconsentgroup.com> wrote:

...

This is great James, thanks.

- M

On 4 Sep 2016, at 00:28, James Hazard <james.g.hazard@gmail.com> wrote:

Skeleton of a Privacy Policy derived from the GDPR: http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/ europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard < <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com>james.g.hazard@gmail. <james.g.hazard@gmail.com>com <james.g.hazard@gmail.com>> wrote:

...

It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections.

Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.

There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves).

My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale.

In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.

In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/ eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md

On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes < <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> andrewhughes3000@ <andrewhughes3000@gmail.com>gmail.com <andrewhughes3000@gmail.com>> wrote:

...

Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper < <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com> <agropper@healthurl.com>agropper@healthurl. <agropper@healthurl.com>com <agropper@healthurl.com>> wrote:

...

My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/ne ws/2016/08/29/onc-announces-blockchain-challenge-winners.html (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard < <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> james.g.hazard@gmail. <james.g.hazard@gmail.com>com <james.g.hazard@gmail.com>> wrote:

...

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source&f ile=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-20 15/Policy/Acme_Privacy_Policy.01.md )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> andrewhughes3000@ <andrewhughes3000@gmail.com>gmail.com <andrewhughes3000@gmail.com>> wrote:

> Well, given that GDPR is pan-EU and takes effect soon and has real > financial penalties, I'd say that it's not a bad place to start. > > Rather than dismissing other's proposals, what do you propose > instead? > > I'd love to see what you've got in mind to take the 10 pages down to > the short versions. Also preferably text that works for non-US regulations. > > andrew. > > > > *Andrew Hughes *CISM CISSP > Independent Consultant > *In Turn Information Management Consulting* > > o +1 650.209.7542 > m +1 250.888.9474 > 1249 Palmer Road, > Victoria, BC V8P 2H8 > AndrewHughes3000@gmail.com > ca.linkedin.com/pub/andrew-hughes/a/58/682/ > *Identity Management | IT Governance | Information Security * > > On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper < > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com> > <agropper@healthurl.com> <agropper@healthurl.com>agropper@healthurl. > <agropper@healthurl.com>com <agropper@healthurl.com>> wrote: > >> The GDPR is useful but not enough. We need to see more companies >> compete on the basis of privacy the way they compete on cost or features. >> To enable that, we need privacy policies that are structured and >> standardized. >> >> A standards-type of organization would need to categorize the >> various kinds of information business and then write a standard privacy >> policy for that category. Businesses would be asked to self-assert a >> category and only list the exceptions for their business relative to the >> standard. Categories could be for banks, telecom, merchants, social media, >> multi-player games, health services, media distribution, government >> services, productivity software, home appliances, and a handful more. It's >> pretty easy to tell which category any given product or service is in terms >> of personal information handling as defined in the GDPR. >> >> Within the categories, we would pull out and structure obvious >> features such as: is a standard API available for 100% of the private >> information they hold (like a calendar or email service do); how does the >> business provide transaction notification to users; prior notification of >> policy changes; does the business ever export de-identified individual >> level data; which national jurisdiction is data processed under; is there a >> right to immediate export and deletion including backups, what technologies >> are used to track users; and a few more like that. >> >> It would not take much to move from the 10-page privacy policies >> and terms of use we have today to a typical policy having 0 to 6 exceptions >> on a single mobile phone screen. >> >> From my perspective as a privacy advocate, simply working toward >> model clauses or applying CommonAccord to GDPR would be helpful but it >> could also be a distraction at a time when we need to make very rapid >> progress to avoid a crisis. Do we really believe that GDPR and HIPAA are >> the future or are they just the camel's nose under a very shaky tent? >> >> Adrian >> >> On Fri, Sep 2, 2016 at 8:05 PM, James Hazard < >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >> james.g.hazard@gmail. <james.g.hazard@gmail.com>com >> <james.g.hazard@gmail.com>> wrote: >> >>> Great work! >>> >>> As we considered "consent" vs other words in the conversation >>> today, the GDPR's vocabulary seemed important, because it is likely to have >>> great influence on privacy, in Europe and outside. >>> http://www.commonaccord.org/index.php?action=doc&fi >>> le=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md >>> >>> A thought occurred to me - what if privacy policies and similar >>> agreements relating to privacy mapped to the organization of provisions of >>> the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. >>> This would provide a base for a common taxonomy. The taxonomy would prove >>> inadequate or undesirable, at least in detail, in many circumstances, but >>> it is an influential starting place. >>> >>> Some time ago, I played with this notion in connection with the >>> CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the >>> CPBR calls for organizations (like Kantara?) to create charters that can be >>> used by companies. I played out the idea as a privacy policy that >>> referenced a charter, which in turn mapped to (was mostly made from) the >>> CPBR. The resulting privacy policy is goofy, but it demonstrates a >>> chain-of-text that connects all the layers of the conversation. >>> >>> http://www.commonaccord.org/index.php?action=list&file=Wx/go >>> v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ >>> >>> The GDPR has the additional advantage of being quite complete, >>> actually enacted, available in many languages, etc. >>> http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu >>> /europa/eur-lex/GDPR/Form/0.md#Article.Sec >>> >>> On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote: >>> >>>> http://kantarainitiative.org/confluence/display/uma/UMA+lega >>>> l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 >>>> 2016-09-02 >>>> >>>> - Working session on User-Managed Access (UMA) in Contractual >>>> and Regulatory Contexts >>>> <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> >>>> - Eve will try to press ahead with lots of editing AIs >>>> prior to the call >>>> - Adrian and Kathleen have sent various suggestions in >>>> list/private email in the last month we should review >>>> >>>> Attending: Eve, Kathleen, Ann, John W, Mary, Jim >>>> >>>> We did a ton of work in the document. >>>> >>>> If you haven't seen it, the latest version of the slides with the >>>> "legal use cases" is here >>>> <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. >>>> Please feel free to share it. >>>> >>>> See also Jim's CommonAccord capture of the GDPR >>>> <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> >>>> . >>>> >>>> >>>> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: >>>> @xmlgrrl >>>> >>>> >>>> _______________________________________________ >>>> WG-UMA mailing list >>>> WG-UMA@kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>> >>>> >>> >>> >>> -- >>> @commonaccord >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! >> HELP us fight for the right to control personal health data. >> DONATE: http://patientprivacyrights.org/donate-2/ >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA@kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> >

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

-- @commonaccord

-- @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE:http://patientprivacyrights.org/donate-2/

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.

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

James;  For a rough list see Appendix A in the 0.8 draft of the consent receipt spec http://kantarainitiative.org/confluence/download/attachments/76447870/KI-CR08-DRAFT-Recommendation.doc?version=1&modificationDate=1470988059000&api=v2 John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin On Sun, Sep 4, 2016 at 11:33 AM -0400, "James Hazard" <james.g.hazard@gmail.com> wrote: Adrian,  Thanks.  Happy to support this direction.  The GDPR seems a good base.   The piece on PDF and Mozart is great, working my way through it. All,  If someone has a favorite, even rough, list for any of the specifics, e.g., purpose, data categories ..., I'd put it in, to allow experimenting. Jim On Sun, Sep 4, 2016 at 9:05 AM, Adrian Gropper <agropper@healthurl.com> wrote: John- Thank you for the thoughtful distinction between the role of standards groups like Kantara and advocacy groups like PPR in regulatory capture. PPR has spent much energy in analyzing privacy policies as a result of work we've done to develop and apply our Framework. I spend pretty much all of my time analyzing the privacy impact of standards. These two activities of PPR parallel the two sides of regulatory capture - political and technical - to oversimplify your analysis. Which brings us back to CommonAccord and related efforts to structure privacy policies that typically are designed to protect the asymmetry that advocates might try to reduce. Wouldn't the introduction of CommonAccord make PPR's job much easier? For example, a paper like the recent one from EPFL (attached), shows how hard it can be to reduce privacy practices to a useful feature description. The introduction of CommonAccord would make that analysis easier to the extent that GDPR is well designed and forces a clear link between privacy practices and privacy policies - as your comment teaches. The application of CommonAccord to GDPR could transform the landscape for regulatory capture if CommonAccord is voluntarily adopted by industry in writing their policies or even if a new generation of academics like Prof. Sweeny's or EPFL decides to use natural language processing to map privacy policies into CommonAccord after the fact. I'm not sure what all this says about the standards work of Kantara and others. UMA-legal, for example, might double down on focusing on GDPR and CommonAccord before looking at the more general problem. That would be interesting. Adrian On Sun, Sep 4, 2016 at 7:46 AM, John Wunderlich <john@wunderlich.ca> wrote: Adrian; Regulatory capture is usually dealt with politically rather than culturally. Witness the activism around net neutrality - there appeared to be real risks of regulatory capture there. WRT to Uber/Lyft competing on privacy I'd say the following: 1. THe privacy notice published serves as a warranty to protect corporate risk. These documents aren't and shouldn't be expected to serve a primary purpose of protecting customer privacy.2. If a company wants to compete on privacy it will do it by     A) designing and producing products and services with privacy in mind (Privacy by Design if you will)    B) Including privacy in marketing and product/service documentation    C) Making sure that the privacy notice (public) and the privacy policy (internal) align with the privacy goals. By claiming privacy in marketing, then managing corporate risk will require appropriate updates to the privacy notice3. In a duopoly or network dominated market, competition is usually not a primary determinant of corporate behaviour. Competition requires a market that is not so clearly dominated by 1 or a few significant players. If a privacy related technology were a disruptive technology it might change the market, and maybe there is a VRM related technology that can serve that role (ahem, JLINC data provenance for example). 4. Change in these market requires regulatory intervention or some other external pressure (like Patient Privacy Rights in health, EFF, EPIC, CDT, Privacy International and so on). As breach publicity rises and as the cost of violating privacy (class action law suits, new and expensive privacy rules and regultarions then (to point 1) managing corporate privacy risks will have to address these concerns. In other words, business/technical initiatives like VRM and/or Kantara can develop and provide the tools or innovations to enable the possibility of increased patient/customer autonomy. This creates the the potential to address the power imbalance between Alice and EvilBobCo but without public awareness and pressure to help develop market demand and make regulatory allowances, it will be a much harder row to hoe. John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin _____________________________ From: Adrian Gropper <agropper@healthurl.com> Sent: Saturday, September 3, 2016 11:26 PM Subject: Re: [WG-UMA] Notes from UMA legal telecon 2016-09-02 To: Mark OCG <m.lizar@openconsentgroup.com> Cc: Deborah Peel <dpeelmd@patientprivacyrights.org>, wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org> I agree with John's explanation of regulatory capture. The way to address it is unclear to me. It's not a standards problem. It's probably a culture problem. Let's assume we want companies to compete on privacy the way they compete on cost or convenience. A company would then have to be able distinguish itself by highlighting specific privacy features that their competitor does not offer. They would use bold bullet points for privacy the way others do for price, acceleration, or mileage. imagine two companies selling ride-sharing services, say, Uber and Lyft, with access to all sorts of personal info including phone, locations, credit card, and some social network components. How would one of these companies use Jim's Skeleton of a Privacy Policy below to differentiate themselves? Adrian On Saturday, September 3, 2016, Mark OCG <m.lizar@openconsentgroup.com> wrote: This is great James, thanks.  - M  On 4 Sep 2016, at 00:28, James Hazard <james.g.hazard@gmail.com> wrote: Skeleton of a Privacy Policy derived from the GDPR:http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md   On Sat, Sep 3, 2016 at 1:44 PM, James Hazard <james.g.hazard@gmail.com> wrote: It can be seen as a conversation.  There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between.  The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections. Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.  There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves). My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale. In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.  In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md      On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote: Nobody ever said that you were critical about CommonAccord. The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.   I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways. Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra. Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.  You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly. What do you say? Charter up and get going? Andrew.Kantara Initiative Leadership Council Chair Andrew Hughes CISM CISSP  Independent Consultant In Turn Information Management Consulting o  +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com  ca.linkedin.com/pub/andrew-hughes/a/58/682/ Identity Management | IT Governance | Information Security  On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com> wrote: My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.  My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result. The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself. My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR. One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-... (Hint: read paper #13 first to get a very nice introduction to why #7.) Adrian On Sat, Sep 3, 2016 at 10:08 AM, James Hazard <james.g.hazard@gmail.com> wrote: Thanks.  I agree fully fully with both comments, except for the part where Adrian claims to disagree. Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy.http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md ) Yes, there are different policies for different settings.  The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc.  So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy. The GDPR provides an excellent base for this.  I'll spin up a first-level repackaging and see how it goes.  On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote: Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start. Rather than dismissing other's proposals, what do you propose instead?   I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations. andrew. Andrew Hughes CISM CISSP  Independent Consultant In Turn Information Management Consulting o  +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com  ca.linkedin.com/pub/andrew-hughes/a/58/682/ Identity Management | IT Governance | Information Security  On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper <agropper@healthurl.com> wrote: The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized. A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR. Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.  It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian On Fri, Sep 2, 2016 at 8:05 PM, James Hazard <james.g.hazard@gmail.com> wrote: Great work!  As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR.  This would provide a base for a common taxonomy.  The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.   Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights.  Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies.  I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR.  The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation. http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc.  http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote: http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... session on User-Managed Access (UMA) in Contractual and Regulatory ContextsEve will try to press ahead with lots of editing AIs prior to the callAdrian and Kathleen have sent various suggestions in list/private email in the last month we should review Attending: Eve, Kathleen, Ann, John W, Mary, Jim We did a ton of work in the document. If you haven't seen it, the latest version of the slides with the "legal use cases" is here. Please feel free to share it. See also Jim's CommonAccord capture of the GDPR. Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma --  @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma --  Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma --  @commonaccord --  Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ --  @commonaccord --  @commonaccord_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE:http://patientprivacyrights.org/donate-2/ 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. -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma -- @commonaccord -- 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.

John, Thanks, the lists are perfect. Jim On Sun, Sep 4, 2016 at 12:10 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:

Posting as someone with just enough knowledge to be dangerous...

If these WGs were to create a set of stable lists, would they be suitable for listing at IANA? (or have I mashed things together that are too different?)

Or if not IANA, is registry for these kinds of lists (besides Kantara's Trust Registry)?

andrew.

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Sun, Sep 4, 2016 at 9:04 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

James;

For a rough list see Appendix A in the 0.8 draft of the consent receipt spec http://kantarainitiative.org/confluence/download/attachments /76447870/KI-CR08-DRAFT-Recommendation.doc?version=1& modificationDate=1470988059000&api=v2

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Sun, Sep 4, 2016 at 11:33 AM -0400, "James Hazard" < james.g.hazard@gmail.com> wrote:

Adrian,

...

Thanks. Happy to support this direction. The GDPR seems a good base.

The piece on PDF and Mozart is great, working my way through it.

All,

If someone has a favorite, even rough, list for any of the specifics, e.g., purpose, data categories ..., I'd put it in, to allow experimenting.

Jim

On Sun, Sep 4, 2016 at 9:05 AM, Adrian Gropper <agropper@healthurl.com> wrote:

...

John-

Thank you for the thoughtful distinction between the role of standards groups like Kantara and advocacy groups like PPR in regulatory capture. PPR has spent much energy in analyzing privacy policies as a result of work we've done to develop and apply our Framework. I spend pretty much all of my time analyzing the privacy impact of standards. These two activities of PPR parallel the two sides of regulatory capture - political and technical - to oversimplify your analysis.

Which brings us back to CommonAccord and related efforts to structure privacy policies that typically are designed to protect the asymmetry that advocates might try to reduce. Wouldn't the introduction of CommonAccord make PPR's job much easier?

For example, a paper like the recent one from EPFL (attached), shows how hard it can be to reduce privacy practices to a useful feature description. The introduction of CommonAccord would make that analysis easier to the extent that GDPR is well designed and forces a clear link between privacy practices and privacy policies - as your comment teaches.

The application of CommonAccord to GDPR could transform the landscape for regulatory capture if CommonAccord is voluntarily adopted by industry in writing their policies or even if a new generation of academics like Prof. Sweeny's or EPFL decides to use natural language processing to map privacy policies into CommonAccord after the fact.

I'm not sure what all this says about the standards work of Kantara and others. UMA-legal, for example, might double down on focusing on GDPR and CommonAccord before looking at the more general problem. That would be interesting.

Adrian

On Sun, Sep 4, 2016 at 7:46 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Adrian;

Regulatory capture is usually dealt with politically rather than culturally. Witness the activism around net neutrality - there appeared to be real risks of regulatory capture there.

WRT to Uber/Lyft competing on privacy I'd say the following:

1. THe privacy notice published serves as a warranty to protect corporate risk. These documents aren't and shouldn't be expected to serve a primary purpose of protecting customer privacy. 2. If a company wants to compete on privacy it will do it by A) designing and producing products and services with privacy in mind (Privacy by Design if you will) B) Including privacy in marketing and product/service documentation C) Making sure that the privacy notice (public) and the privacy policy (internal) align with the privacy goals. By claiming privacy in marketing, then managing corporate risk will require appropriate updates to the privacy notice 3. In a duopoly or network dominated market, competition is usually not a primary determinant of corporate behaviour. Competition requires a market that is not so clearly dominated by 1 or a few significant players. If a privacy related technology were a disruptive technology it might change the market, and maybe there is a VRM related technology that can serve that role (ahem, JLINC data provenance for example). 4. Change in these market requires regulatory intervention or some other external pressure (like Patient Privacy Rights in health, EFF, EPIC, CDT, Privacy International and so on). As breach publicity rises and as the cost of violating privacy (class action law suits, new and expensive privacy rules and regultarions then (to point 1) managing corporate privacy risks will have to address these concerns.

In other words, business/technical initiatives like VRM and/or Kantara can develop and provide the tools or innovations to enable the possibility of increased patient/customer autonomy. This creates the the potential to address the power imbalance between Alice and EvilBobCo but without public awareness and pressure to help develop market demand and make regulatory allowances, it will be a much harder row to hoe.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: Adrian Gropper <agropper@healthurl.com> Sent: Saturday, September 3, 2016 11:26 PM Subject: Re: [WG-UMA] Notes from UMA legal telecon 2016-09-02 To: Mark OCG <m.lizar@openconsentgroup.com> Cc: Deborah Peel <dpeelmd@patientprivacyrights.org>, wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org>

I agree with John's explanation of regulatory capture. The way to address it is unclear to me. It's not a standards problem. It's probably a culture problem.

Let's assume we want companies to compete on privacy the way they compete on cost or convenience. A company would then have to be able distinguish itself by highlighting specific privacy features that their competitor does not offer. They would use bold bullet points for privacy the way others do for price, acceleration, or mileage.

imagine two companies selling ride-sharing services, say, Uber and Lyft, with access to all sorts of personal info including phone, locations, credit card, and some social network components. How would one of these companies use Jim's Skeleton of a Privacy Policy below to differentiate themselves?

Adrian

On Saturday, September 3, 2016, Mark OCG <m.lizar@openconsentgroup.com> wrote:

...

This is great James, thanks.

- M

On 4 Sep 2016, at 00:28, James Hazard <james.g.hazard@gmail.com> wrote:

Skeleton of a Privacy Policy derived from the GDPR: http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/ europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard < <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> james.g.hazard@gmail. <james.g.hazard@gmail.com>com <james.g.hazard@gmail.com>> wrote:

> It can be seen as a conversation. There are large-scale actors > (e.g., companies and governments) and small scale (e.g., individuals, > families, friends) and all sizes in between. The large ones are assisted > in the conversation, the small ones less so, often not at all and often > only indirectly by friends, reputations or legal protections. > > Working text as chains - with provenance and targets for > collaboration, rating, comment, law - can improve communication in the > conversation. > > There are strong reasons for collective action (such as the GDPR) > and also strong reasons for small-scale autonomy (adaptation to > circumstance, avoidance monoculture, maintenance of habits and benefits of > people deciding things for themselves). > > My expectation of text-chains (e.g. CommonAccord) is that they will > accelerate some kinds of displacements, but my hope is that they will also > reduce the friction (cost, delay, risk) of small-scale self-governance, > enabling smaller groups to retain independence instead of being overwhelmed > by large scale. > > In any event, the document-orientation and extensibility mean that > people can use the materials like they current use word-processed documents > (the most decentralized system of self-governance we have), but with > greater efficiency, aggregation of social knowledge and, to some extent, > collective bargaining power. > > In an improvised way, I gave names to the various sections of the > GDPR as a preliminary to experimenting with documents like privacy policies > and data transfer agreements that build on the GDPR - > http://www.commonaccord.org/index.php?action=source&file=Wx/ > eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md > > > > On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes < > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> > andrewhughes3000@ <andrewhughes3000@gmail.com>gmail.com > <andrewhughes3000@gmail.com>> wrote: > >> Nobody ever said that you were critical about CommonAccord. >> >> The issue I see is that there's lots of non-productive text >> pointing out that this group is failing to address the challenges you >> identify. >> >> I don't really understand the phrase "regulatory capture". Without >> regulations, organizations won't change en masse - those enlightened >> organizations may see some advantage in early action, but will be outliers >> until social norms (and eventually regulations) catch up to them. Kantara >> aims squarely at the needs of organizations within their markets - which >> includes regulators and customer/consumers/clients (and many other actors). >> I have not done an in-depth analysis of the state of regulation and the >> internet - but a cursory survey tells me that the unregulated spaces tend >> to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, >> Google, etc) which are capture audiences in different ways. >> >> Stating that "Kantara" has a view on prioritizing industry versus >> individual interests is a false argument. Kantara's view and place in the >> ecosystem is the result of its members input and work. It has no >> organizational position or viewpoint of its own. Kantara provides >> innovators the tools and space and freedom to meet and discuss ways to >> change the world - neutral and open is the mantra. >> >> Will you lead a new Kantara Discussion Group to further explore the >> imbalances in the ecosystem that cause "industry interests" to trump >> "individual interests"? Because that's the mechanism to include topics like >> that in Kantara's scope. Trying to force other WGs to look at issues >> tangential to their mandates isn't going to work very well. >> >> You will get strong participation in such a DG - there are many in >> the Consent and Information Sharing, UMA, , myData, Personal Data >> Ecosystem, and other communities that would be enthusiastic contributors. >> The DG would be supported in writing a Kantara Report that assists the >> other DG/WG on understanding the issues and aligning correctly. >> >> What do you say? Charter up and get going? >> >> Andrew. >> Kantara Initiative Leadership Council Chair >> >> >> *Andrew Hughes *CISM CISSP >> Independent Consultant >> *In Turn Information Management Consulting* >> >> o +1 650.209.7542 >> m +1 250.888.9474 >> 1249 Palmer Road, >> Victoria, BC V8P 2H8 >> AndrewHughes3000@gmail.com >> ca.linkedin.com/pub/andrew-hughes/a/58/682/ >> *Identity Management | IT Governance | Information Security * >> >> On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper < >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> <agropper@healthurl.com> <agropper@healthurl.com> >> agropper@healthurl. <agropper@healthurl.com>com >> <agropper@healthurl.com>> wrote: >> >>> My comment was in no way a criticism of CommonAccord. I have >>> supported that project for years and it's still the only thing like it that >>> I know of and it makes sense. >>> >>> My comment is critical of regulatory capture and the way we >>> translate innovations like CommonAccord and regulatory initiatives like >>> GDPR into industry practice. Governance is at the heart of the issue. The >>> standards mechanism, including Kantara, is not set up to put individual and >>> civil society interests above industry interests. Regulatory mechanisms >>> like GDPR and the US "Meaningful Use" debacle are not set up to create >>> standards. Regulatory capture is the result. >>> >>> The places I've experienced pushback on regulatory capture is UMA, >>> (where, under Eve's leadership, we have consistently sought to widen the >>> ecosystem and consider individual rights equal to institutional) and the >>> blockchain communities where avoiding regulatory capture is a religion in >>> itself. >>> >>> My comment, which was obviously unclear, was a call for us to >>> consider the governance mechanisms that might result in creating structured >>> and standardized privacy policies based on CommonAccord and GDPR. >>> >>> One place where we're trying to make a dent in this governance >>> issue is W3C. The idea is to convene an outcome-driven community (not a >>> standards-track process) designed to combine UMA and blockchain and other >>> standards to create a "stack" of protocols that captures the fundamentals >>> of privacy engineering and re-balances the power of individuals over >>> institutions. W3C Verifiable Claims is another example of a standard that >>> will be core to privacy engineering if it survives regulatory capture. You >>> can read about this as paper #7 at http://www.hhs.gov/about/ne >>> ws/2016/08/29/onc-announces-blockchain-challenge-winners.html (Hint: >>> read paper #13 first to get a very nice introduction to why #7.) >>> >>> Adrian >>> >>> On Sat, Sep 3, 2016 at 10:08 AM, James Hazard < >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>> james.g.hazard@gmail. <james.g.hazard@gmail.com>com >>> <james.g.hazard@gmail.com>> wrote: >>> >>>> Thanks. I agree fully fully with both comments, except for the >>>> part where Adrian claims to disagree. >>>> >>>> Yes, the "end-user" (aka "human") gets a short list of diffs from >>>> some base (here a _very_ short list, on the CPBR policy. >>>> http://www.commonaccord.org/index.php?action=source&f >>>> ile=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-20 >>>> 15/Policy/Acme_Privacy_Policy.01.md ) >>>> >>>> Yes, there are different policies for different settings. The >>>> range of "settings" is vast - not only industry, but also jurisdiction and >>>> language, characteristics of the human (child, disabled, married, employed, >>>> related), etc. So the system needs to be extensible - a person on "the >>>> edge" can autonomously extend any existing end point and enrich the >>>> taxonomy. >>>> >>>> The GDPR provides an excellent base for this. I'll spin up a >>>> first-level repackaging and see how it goes. >>>> >>>> >>>> >>>> On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> <andrewhughes3000@gmail.com> <andrewhughes3000@gmail.com> >>>> andrewhughes3000@ <andrewhughes3000@gmail.com>gmail.com >>>> <andrewhughes3000@gmail.com>> wrote: >>>> >>>>> Well, given that GDPR is pan-EU and takes effect soon and has >>>>> real financial penalties, I'd say that it's not a bad place to start. >>>>> >>>>> Rather than dismissing other's proposals, what do you propose >>>>> instead? >>>>> >>>>> I'd love to see what you've got in mind to take the 10 pages >>>>> down to the short versions. Also preferably text that works for non-US >>>>> regulations. >>>>> >>>>> andrew. >>>>> >>>>> >>>>> >>>>> *Andrew Hughes *CISM CISSP >>>>> Independent Consultant >>>>> *In Turn Information Management Consulting* >>>>> >>>>> o +1 650.209.7542 >>>>> m +1 250.888.9474 >>>>> 1249 Palmer Road, >>>>> Victoria, BC V8P 2H8 >>>>> AndrewHughes3000@gmail.com >>>>> ca.linkedin.com/pub/andrew-hughes/a/58/682/ >>>>> *Identity Management | IT Governance | Information Security * >>>>> >>>>> On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper < >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> <agropper@healthurl.com> <agropper@healthurl.com> >>>>> agropper@healthurl. <agropper@healthurl.com>com >>>>> <agropper@healthurl.com>> wrote: >>>>> >>>>>> The GDPR is useful but not enough. We need to see more >>>>>> companies compete on the basis of privacy the way they compete on cost or >>>>>> features. To enable that, we need privacy policies that are structured and >>>>>> standardized. >>>>>> >>>>>> A standards-type of organization would need to categorize the >>>>>> various kinds of information business and then write a standard privacy >>>>>> policy for that category. Businesses would be asked to self-assert a >>>>>> category and only list the exceptions for their business relative to the >>>>>> standard. Categories could be for banks, telecom, merchants, social media, >>>>>> multi-player games, health services, media distribution, government >>>>>> services, productivity software, home appliances, and a handful more. It's >>>>>> pretty easy to tell which category any given product or service is in terms >>>>>> of personal information handling as defined in the GDPR. >>>>>> >>>>>> Within the categories, we would pull out and structure obvious >>>>>> features such as: is a standard API available for 100% of the private >>>>>> information they hold (like a calendar or email service do); how does the >>>>>> business provide transaction notification to users; prior notification of >>>>>> policy changes; does the business ever export de-identified individual >>>>>> level data; which national jurisdiction is data processed under; is there a >>>>>> right to immediate export and deletion including backups, what technologies >>>>>> are used to track users; and a few more like that. >>>>>> >>>>>> It would not take much to move from the 10-page privacy >>>>>> policies and terms of use we have today to a typical policy having 0 to 6 >>>>>> exceptions on a single mobile phone screen. >>>>>> >>>>>> From my perspective as a privacy advocate, simply working >>>>>> toward model clauses or applying CommonAccord to GDPR would be helpful but >>>>>> it could also be a distraction at a time when we need to make very rapid >>>>>> progress to avoid a crisis. Do we really believe that GDPR and HIPAA are >>>>>> the future or are they just the camel's nose under a very shaky tent? >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Fri, Sep 2, 2016 at 8:05 PM, James Hazard < >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> <james.g.hazard@gmail.com> <james.g.hazard@gmail.com> >>>>>> james.g.hazard@gmail. <james.g.hazard@gmail.com>com >>>>>> <james.g.hazard@gmail.com>> wrote: >>>>>> >>>>>>> Great work! >>>>>>> >>>>>>> As we considered "consent" vs other words in the conversation >>>>>>> today, the GDPR's vocabulary seemed important, because it is likely to have >>>>>>> great influence on privacy, in Europe and outside. >>>>>>> http://www.commonaccord.org/index.php?action=doc&fi >>>>>>> le=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md >>>>>>> >>>>>>> A thought occurred to me - what if privacy policies and >>>>>>> similar agreements relating to privacy mapped to the organization of >>>>>>> provisions of the GDPR and reused, to the extent reasonable, the vocabulary >>>>>>> of the GDPR. This would provide a base for a common taxonomy. The >>>>>>> taxonomy would prove inadequate or undesirable, at least in detail, in many >>>>>>> circumstances, but it is an influential starting place. >>>>>>> >>>>>>> Some time ago, I played with this notion in connection with >>>>>>> the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, >>>>>>> the CPBR calls for organizations (like Kantara?) to create charters that >>>>>>> can be used by companies. I played out the idea as a privacy policy that >>>>>>> referenced a charter, which in turn mapped to (was mostly made from) the >>>>>>> CPBR. The resulting privacy policy is goofy, but it demonstrates a >>>>>>> chain-of-text that connects all the layers of the conversation. >>>>>>> >>>>>>> http://www.commonaccord.org/index.php?action=list&file=Wx/go >>>>>>> v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ >>>>>>> >>>>>>> The GDPR has the additional advantage of being quite complete, >>>>>>> actually enacted, available in many languages, etc. >>>>>>> http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu >>>>>>> /europa/eur-lex/GDPR/Form/0.md#Article.Sec >>>>>>> >>>>>>> On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> >>>>>>> wrote: >>>>>>> >>>>>>>> http://kantarainitiative.org/confluence/display/uma/UMA+lega >>>>>>>> l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 >>>>>>>> 2016-09-02 >>>>>>>> >>>>>>>> - Working session on User-Managed Access (UMA) in >>>>>>>> Contractual and Regulatory Contexts >>>>>>>> <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> >>>>>>>> - Eve will try to press ahead with lots of editing AIs >>>>>>>> prior to the call >>>>>>>> - Adrian and Kathleen have sent various suggestions in >>>>>>>> list/private email in the last month we should review >>>>>>>> >>>>>>>> Attending: Eve, Kathleen, Ann, John W, Mary, Jim >>>>>>>> >>>>>>>> We did a ton of work in the document. >>>>>>>> >>>>>>>> If you haven't seen it, the latest version of the slides with >>>>>>>> the "legal use cases" is here >>>>>>>> <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. >>>>>>>> Please feel free to share it. >>>>>>>> >>>>>>>> See also Jim's CommonAccord capture of the GDPR >>>>>>>> <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: >>>>>>>> @xmlgrrl >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> WG-UMA mailing list >>>>>>>> WG-UMA@kantarainitiative.org >>>>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> @commonaccord >>>>>>> >>>>>>> _______________________________________________ >>>>>>> WG-UMA mailing list >>>>>>> WG-UMA@kantarainitiative.org >>>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Adrian Gropper MD >>>>>> >>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>>>>> HELP us fight for the right to control personal health data. >>>>>> DONATE: http://patientprivacyrights.org/donate-2/ >>>>>> >>>>>> _______________________________________________ >>>>>> WG-UMA mailing list >>>>>> WG-UMA@kantarainitiative.org >>>>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> @commonaccord >>>> >>> >>> >>> >>> -- >>> >>> Adrian Gropper MD >>> >>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>> HELP us fight for the right to control personal health data. >>> DONATE: http://patientprivacyrights.org/donate-2/ >>> >> >> > > > -- > @commonaccord >

-- @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE:http://patientprivacyrights.org/donate-2/

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.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

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-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

Hi Andrew, I think this is great thinking. Purpose list might also be a great discussion group on its own. We have talked about this type of listing in the past. And, its clear that purpose lists harmonisation is required for the new EU single market. Registering a purpose list might itself be a valuable service for trade associations and the like. Also registering icons to purpose - also seems to be a gap. - Mark

On 4 Sep 2016, at 17:10, Andrew Hughes <andrewhughes3000@gmail.com> wrote:

Posting as someone with just enough knowledge to be dangerous...

If these WGs were to create a set of stable lists, would they be suitable for listing at IANA? (or have I mashed things together that are too different?)

Or if not IANA, is registry for these kinds of lists (besides Kantara's Trust Registry)?

andrew.

Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com <mailto:AndrewHughes3000@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

On Sun, Sep 4, 2016 at 9:04 AM, John Wunderlich <john@wunderlich.ca <mailto:john@wunderlich.ca>> wrote: James;

For a rough list see Appendix A in the 0.8 draft of the consent receipt spec http://kantarainitiative.org/confluence/download/attachments/76447870/KI-CR08-DRAFT-Recommendation.doc?version=1&modificationDate=1470988059000&api=v2 <http://kantarainitiative.org/confluence/download/attachments/76447870/KI-CR08-DRAFT-Recommendation.doc?version=1&modificationDate=1470988059000&api=v2>

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Sun, Sep 4, 2016 at 11:33 AM -0400, "James Hazard" <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote:

Adrian,

Thanks. Happy to support this direction. The GDPR seems a good base.

The piece on PDF and Mozart is great, working my way through it.

All,

If someone has a favorite, even rough, list for any of the specifics, e.g., purpose, data categories ..., I'd put it in, to allow experimenting.

Jim

On Sun, Sep 4, 2016 at 9:05 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: John-

Thank you for the thoughtful distinction between the role of standards groups like Kantara and advocacy groups like PPR in regulatory capture. PPR has spent much energy in analyzing privacy policies as a result of work we've done to develop and apply our Framework. I spend pretty much all of my time analyzing the privacy impact of standards. These two activities of PPR parallel the two sides of regulatory capture - political and technical - to oversimplify your analysis.

Which brings us back to CommonAccord and related efforts to structure privacy policies that typically are designed to protect the asymmetry that advocates might try to reduce. Wouldn't the introduction of CommonAccord make PPR's job much easier?

For example, a paper like the recent one from EPFL (attached), shows how hard it can be to reduce privacy practices to a useful feature description. The introduction of CommonAccord would make that analysis easier to the extent that GDPR is well designed and forces a clear link between privacy practices and privacy policies - as your comment teaches.

The application of CommonAccord to GDPR could transform the landscape for regulatory capture if CommonAccord is voluntarily adopted by industry in writing their policies or even if a new generation of academics like Prof. Sweeny's or EPFL decides to use natural language processing to map privacy policies into CommonAccord after the fact.

I'm not sure what all this says about the standards work of Kantara and others. UMA-legal, for example, might double down on focusing on GDPR and CommonAccord before looking at the more general problem. That would be interesting.

Adrian

On Sun, Sep 4, 2016 at 7:46 AM, John Wunderlich <john@wunderlich.ca <mailto:john@wunderlich.ca>> wrote: Adrian;

Regulatory capture is usually dealt with politically rather than culturally. Witness the activism around net neutrality - there appeared to be real risks of regulatory capture there.

WRT to Uber/Lyft competing on privacy I'd say the following:

1. THe privacy notice published serves as a warranty to protect corporate risk. These documents aren't and shouldn't be expected to serve a primary purpose of protecting customer privacy. 2. If a company wants to compete on privacy it will do it by A) designing and producing products and services with privacy in mind (Privacy by Design if you will) B) Including privacy in marketing and product/service documentation C) Making sure that the privacy notice (public) and the privacy policy (internal) align with the privacy goals. By claiming privacy in marketing, then managing corporate risk will require appropriate updates to the privacy notice 3. In a duopoly or network dominated market, competition is usually not a primary determinant of corporate behaviour. Competition requires a market that is not so clearly dominated by 1 or a few significant players. If a privacy related technology were a disruptive technology it might change the market, and maybe there is a VRM related technology that can serve that role (ahem, JLINC data provenance for example). 4. Change in these market requires regulatory intervention or some other external pressure (like Patient Privacy Rights in health, EFF, EPIC, CDT, Privacy International and so on). As breach publicity rises and as the cost of violating privacy (class action law suits, new and expensive privacy rules and regultarions then (to point 1) managing corporate privacy risks will have to address these concerns.

In other words, business/technical initiatives like VRM and/or Kantara can develop and provide the tools or innovations to enable the possibility of increased patient/customer autonomy. This creates the the potential to address the power imbalance between Alice and EvilBobCo but without public awareness and pressure to help develop market demand and make regulatory allowances, it will be a much harder row to hoe.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> Sent: Saturday, September 3, 2016 11:26 PM Subject: Re: [WG-UMA] Notes from UMA legal telecon 2016-09-02 To: Mark OCG <m.lizar@openconsentgroup.com <mailto:m.lizar@openconsentgroup.com>> Cc: Deborah Peel <dpeelmd@patientprivacyrights.org <mailto:dpeelmd@patientprivacyrights.org>>, wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> WG <wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org>>

I agree with John's explanation of regulatory capture. The way to address it is unclear to me. It's not a standards problem. It's probably a culture problem.

Let's assume we want companies to compete on privacy the way they compete on cost or convenience. A company would then have to be able distinguish itself by highlighting specific privacy features that their competitor does not offer. They would use bold bullet points for privacy the way others do for price, acceleration, or mileage.

imagine two companies selling ride-sharing services, say, Uber and Lyft, with access to all sorts of personal info including phone, locations, credit card, and some social network components. How would one of these companies use Jim's Skeleton of a Privacy Policy below to differentiate themselves?

Adrian

On Saturday, September 3, 2016, Mark OCG <m.lizar@openconsentgroup.com <mailto:m.lizar@openconsentgroup.com>> wrote: This is great James, thanks.

- M

On 4 Sep 2016, at 00:28, James Hazard < <>james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote:

Skeleton of a Privacy Policy derived from the GDPR: http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md <http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md>

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard < <> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com>james.g.hazard@gmail. <mailto:james.g.hazard@gmail.com>com <mailto:james.g.hazard@gmail.com>> wrote: It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections.

Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.

There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves).

My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale.

In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.

In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md <http://www.commonaccord.org/index.php?action=source&file=Wx/eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md>

On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes < <> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com>andrewhughes3000@ <mailto:andrewhughes3000@gmail.com>gmail.com <mailto:andrewhughes3000@gmail.com>> wrote: Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting

o +1 650.209.7542 <> m +1 250.888.9474 <> 1249 Palmer Road, Victoria, BC V8P 2H8 <>AndrewHughes3000@gmail.com <mailto:AndrewHughes3000@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

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper < <> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com>agropper@healthurl. <mailto:agropper@healthurl.com>com <mailto:agropper@healthurl.com>> wrote: My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-... <http://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challenge-winners.html> (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard < <> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com>james.g.hazard@gmail. <mailto:james.g.hazard@gmail.com>com <mailto:james.g.hazard@gmail.com>> wrote: Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy.http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md <http://www.commonaccord.org/index.php?action=source&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/Policy/Acme_Privacy_Policy.01.md> )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < <> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com> <mailto:andrewhughes3000@gmail.com>andrewhughes3000@ <mailto:andrewhughes3000@gmail.com>gmail.com <mailto:andrewhughes3000@gmail.com>> wrote: Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting

o +1 650.209.7542 <> m +1 250.888.9474 <> 1249 Palmer Road, Victoria, BC V8P 2H8 <>AndrewHughes3000@gmail.com <mailto:AndrewHughes3000@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

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper < <> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com> <mailto:agropper@healthurl.com>agropper@healthurl. <mailto:agropper@healthurl.com>com <mailto:agropper@healthurl.com>> wrote: The GDPR is useful but not enough. We need to see more companies compete on the basis of privacy the way they compete on cost or features. To enable that, we need privacy policies that are structured and standardized.

A standards-type of organization would need to categorize the various kinds of information business and then write a standard privacy policy for that category. Businesses would be asked to self-assert a category and only list the exceptions for their business relative to the standard. Categories could be for banks, telecom, merchants, social media, multi-player games, health services, media distribution, government services, productivity software, home appliances, and a handful more. It's pretty easy to tell which category any given product or service is in terms of personal information handling as defined in the GDPR.

Within the categories, we would pull out and structure obvious features such as: is a standard API available for 100% of the private information they hold (like a calendar or email service do); how does the business provide transaction notification to users; prior notification of policy changes; does the business ever export de-identified individual level data; which national jurisdiction is data processed under; is there a right to immediate export and deletion including backups, what technologies are used to track users; and a few more like that.

It would not take much to move from the 10-page privacy policies and terms of use we have today to a typical policy having 0 to 6 exceptions on a single mobile phone screen.

From my perspective as a privacy advocate, simply working toward model clauses or applying CommonAccord to GDPR would be helpful but it could also be a distraction at a time when we need to make very rapid progress to avoid a crisis. Do we really believe that GDPR and HIPAA are the future or are they just the camel's nose under a very shaky tent?

Adrian

On Fri, Sep 2, 2016 at 8:05 PM, James Hazard < <> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com> <mailto:james.g.hazard@gmail.com>james.g.hazard@gmail. <mailto:james.g.hazard@gmail.com>com <mailto:james.g.hazard@gmail.com>> wrote: Great work!

As we considered "consent" vs other words in the conversation today, the GDPR's vocabulary seemed important, because it is likely to have great influence on privacy, in Europe and outside. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md>

A thought occurred to me - what if privacy policies and similar agreements relating to privacy mapped to the organization of provisions of the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. This would provide a base for a common taxonomy. The taxonomy would prove inadequate or undesirable, at least in detail, in many circumstances, but it is an influential starting place.

Some time ago, I played with this notion in connection with the CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the CPBR calls for organizations (like Kantara?) to create charters that can be used by companies. I played out the idea as a privacy policy that referenced a charter, which in turn mapped to (was mostly made from) the CPBR. The resulting privacy policy is goofy, but it demonstrates a chain-of-text that connects all the layers of the conversation.

http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ <http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/>

The GDPR has the additional advantage of being quite complete, actually enacted, available in many languages, etc. http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.Sec>

On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler < <>eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02> 2016-09-02 Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> Eve will try to press ahead with lots of editing AIs prior to the call Adrian and Kathleen have sent various suggestions in list/private email in the last month we should review Attending: Eve, Kathleen, Ann, John W, Mary, Jim We did a ton of work in the document. If you haven't seen it, the latest version of the slides with the "legal use cases" is here <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. Please feel free to share it. See also Jim's CommonAccord capture of the GDPR <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec>.

Eve Maler Cell +1 425.345.6756 <> | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list <>WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

_______________________________________________ WG-UMA mailing list <>WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ WG-UMA mailing list <>WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>

-- @commonaccord

-- @commonaccord _______________________________________________ WG-UMA mailing list <>WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE:http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>

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.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

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-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

John, Perfect! Thanks for the thumbs up. Yes, actual use involves combining lists of alternatives. There are a variety of ways to handle this. The best might be to: 1. Make a separate list (page) of alternatives for each of those categories, giving each alternative a different name. These lists can be open-ended (by adding new alternatives as they arise). 2. Use those lists in combinations. Each combination is a separate page, referencing the appropriate alternatives. If a combination requires a tweak or a rewrite of an alternative, that override the referenced alternative. 3. The combination page can be referenced in the Privacy Notice (I did notice your comment) so that collection of alternatives is used. 4. The Privacy Notice should probably present these as part of the kickoff text at the top. (It is possible to selectively override the provisions of the included GDPR text, and that might make sense in some cases, for instance to eliminate unneeded portions. But that can also be confusing.) 5. Both lists of alternatives and combinations can have "official" comments (curated by the author of the page) about their purpose and appropriateness. There can be unofficial comments by others, who link to the page (making it findable in the UsedBy notion). A list of "purposes" might be a good start. It would act as a kind of survey of the field. :) Jim On Sun, Sep 4, 2016 at 7:23 AM, John Wunderlich <john@wunderlich.ca> wrote:

James;

Nice derivation from the GDPR, and I'm already considering using the skeleton with some clients interested in EU compliance and looking for a PIPEDA equivalent in Canada. +1

That being said 5(1)(b) talks about specific purposes. How do you propose (or do you?) to template or list the purposes that the entity has for processing and to articulate the differences between those purposes that are necessary and those that are optional? Further how do you distinguish or articulate or identify personal data that requires consent and which data and/or purposes is processed under authorities other than consent (Article 6).

I know you call it a skeleton, and as above I think it's terrific. But creating a meaningful privacy notice (noting that what is normally published for customers as a privacy policy is actually a privacy notice and that a privacy policy is an internal document to provide guidance and procedures to staff) will require an understanding of the actual and specific purposes and uses of that data (or categories of data). This will mean, I think, adding purposes, uses, and authority to the template.

I note the complexity of matching multiple data categories to multiple purposes under multiple authorities. If the entity collects 3 categories of information, for three different purposes, under 3 different authorities you end up with 3^3 or 27 different personal data-purpose-authority scenarios. Even if you don't do this level of granularity for the privacy notice, if you are the DPO, you would want to map them out so that you can identify null set scenarios and prioritize and manage risk for the rest - partially by ensuring the the significant scenarios are included in the privacy notice published.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: James Hazard <james.g.hazard@gmail.com> Sent: Saturday, September 3, 2016 7:28 PM Subject: Re: [WG-UMA] Notes from UMA legal telecon 2016-09-02 To: Andrew Hughes <andrewhughes3000@gmail.com> Cc: Deborah Peel <dpeelmd@patientprivacyrights.org>, wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org>

Skeleton of a Privacy Policy derived from the GDPR: http://www.commonaccord.org/index.php?action=doc&file=Wx/ eu/europa/eur-lex/GDPR/PrivacyPolicy/Form/0.md

On Sat, Sep 3, 2016 at 1:44 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

It can be seen as a conversation. There are large-scale actors (e.g., companies and governments) and small scale (e.g., individuals, families, friends) and all sizes in between. The large ones are assisted in the conversation, the small ones less so, often not at all and often only indirectly by friends, reputations or legal protections.

Working text as chains - with provenance and targets for collaboration, rating, comment, law - can improve communication in the conversation.

There are strong reasons for collective action (such as the GDPR) and also strong reasons for small-scale autonomy (adaptation to circumstance, avoidance monoculture, maintenance of habits and benefits of people deciding things for themselves).

My expectation of text-chains (e.g. CommonAccord) is that they will accelerate some kinds of displacements, but my hope is that they will also reduce the friction (cost, delay, risk) of small-scale self-governance, enabling smaller groups to retain independence instead of being overwhelmed by large scale.

In any event, the document-orientation and extensibility mean that people can use the materials like they current use word-processed documents (the most decentralized system of self-governance we have), but with greater efficiency, aggregation of social knowledge and, to some extent, collective bargaining power.

In an improvised way, I gave names to the various sections of the GDPR as a preliminary to experimenting with documents like privacy policies and data transfer agreements that build on the GDPR - http://www.commonaccord.org/index.php?action=source&file=Wx/ eu/europa/eur-lex/GDPR/Sec/Article/ListSemantic.md

On Sat, Sep 3, 2016 at 12:52 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

...

Nobody ever said that you were critical about CommonAccord.

The issue I see is that there's lots of non-productive text pointing out that this group is failing to address the challenges you identify.

I don't really understand the phrase "regulatory capture". Without regulations, organizations won't change en masse - those enlightened organizations may see some advantage in early action, but will be outliers until social norms (and eventually regulations) catch up to them. Kantara aims squarely at the needs of organizations within their markets - which includes regulators and customer/consumers/clients (and many other actors). I have not done an in-depth analysis of the state of regulation and the internet - but a cursory survey tells me that the unregulated spaces tend to spawn powerful walled-garden oligopolies or monopolies (Uber, Facebook, Google, etc) which are capture audiences in different ways.

Stating that "Kantara" has a view on prioritizing industry versus individual interests is a false argument. Kantara's view and place in the ecosystem is the result of its members input and work. It has no organizational position or viewpoint of its own. Kantara provides innovators the tools and space and freedom to meet and discuss ways to change the world - neutral and open is the mantra.

Will you lead a new Kantara Discussion Group to further explore the imbalances in the ecosystem that cause "industry interests" to trump "individual interests"? Because that's the mechanism to include topics like that in Kantara's scope. Trying to force other WGs to look at issues tangential to their mandates isn't going to work very well.

You will get strong participation in such a DG - there are many in the Consent and Information Sharing, UMA, , myData, Personal Data Ecosystem, and other communities that would be enthusiastic contributors. The DG would be supported in writing a Kantara Report that assists the other DG/WG on understanding the issues and aligning correctly.

What do you say? Charter up and get going?

Andrew. Kantara Initiative Leadership Council Chair

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Sat, Sep 3, 2016 at 8:48 AM, Adrian Gropper <agropper@healthurl.com> wrote:

...

My comment was in no way a criticism of CommonAccord. I have supported that project for years and it's still the only thing like it that I know of and it makes sense.

My comment is critical of regulatory capture and the way we translate innovations like CommonAccord and regulatory initiatives like GDPR into industry practice. Governance is at the heart of the issue. The standards mechanism, including Kantara, is not set up to put individual and civil society interests above industry interests. Regulatory mechanisms like GDPR and the US "Meaningful Use" debacle are not set up to create standards. Regulatory capture is the result.

The places I've experienced pushback on regulatory capture is UMA, (where, under Eve's leadership, we have consistently sought to widen the ecosystem and consider individual rights equal to institutional) and the blockchain communities where avoiding regulatory capture is a religion in itself.

My comment, which was obviously unclear, was a call for us to consider the governance mechanisms that might result in creating structured and standardized privacy policies based on CommonAccord and GDPR.

One place where we're trying to make a dent in this governance issue is W3C. The idea is to convene an outcome-driven community (not a standards-track process) designed to combine UMA and blockchain and other standards to create a "stack" of protocols that captures the fundamentals of privacy engineering and re-balances the power of individuals over institutions. W3C Verifiable Claims is another example of a standard that will be core to privacy engineering if it survives regulatory capture. You can read about this as paper #7 at http://www.hhs.gov/about/news/ 2016/08/29/onc-announces-blockchain-challenge-winners.html (Hint: read paper #13 first to get a very nice introduction to why #7.)

Adrian

On Sat, Sep 3, 2016 at 10:08 AM, James Hazard <james.g.hazard@gmail.com

...

wrote:

...

Thanks. I agree fully fully with both comments, except for the part where Adrian claims to disagree.

Yes, the "end-user" (aka "human") gets a short list of diffs from some base (here a _very_ short list, on the CPBR policy. http://www.commonaccord.org/index.php?action=source&f ile=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-20 15/Policy/Acme_Privacy_Policy.01.md )

Yes, there are different policies for different settings. The range of "settings" is vast - not only industry, but also jurisdiction and language, characteristics of the human (child, disabled, married, employed, related), etc. So the system needs to be extensible - a person on "the edge" can autonomously extend any existing end point and enrich the taxonomy.

The GDPR provides an excellent base for this. I'll spin up a first-level repackaging and see how it goes.

On Fri, Sep 2, 2016 at 10:36 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:

...

Well, given that GDPR is pan-EU and takes effect soon and has real financial penalties, I'd say that it's not a bad place to start.

Rather than dismissing other's proposals, what do you propose instead?

I'd love to see what you've got in mind to take the 10 pages down to the short versions. Also preferably text that works for non-US regulations.

andrew.

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

On Fri, Sep 2, 2016 at 6:22 PM, Adrian Gropper < agropper@healthurl.com> wrote:

> The GDPR is useful but not enough. We need to see more companies > compete on the basis of privacy the way they compete on cost or features. > To enable that, we need privacy policies that are structured and > standardized. > > A standards-type of organization would need to categorize the > various kinds of information business and then write a standard privacy > policy for that category. Businesses would be asked to self-assert a > category and only list the exceptions for their business relative to the > standard. Categories could be for banks, telecom, merchants, social media, > multi-player games, health services, media distribution, government > services, productivity software, home appliances, and a handful more. It's > pretty easy to tell which category any given product or service is in terms > of personal information handling as defined in the GDPR. > > Within the categories, we would pull out and structure obvious > features such as: is a standard API available for 100% of the private > information they hold (like a calendar or email service do); how does the > business provide transaction notification to users; prior notification of > policy changes; does the business ever export de-identified individual > level data; which national jurisdiction is data processed under; is there a > right to immediate export and deletion including backups, what technologies > are used to track users; and a few more like that. > > It would not take much to move from the 10-page privacy policies and > terms of use we have today to a typical policy having 0 to 6 exceptions on > a single mobile phone screen. > > From my perspective as a privacy advocate, simply working toward > model clauses or applying CommonAccord to GDPR would be helpful but it > could also be a distraction at a time when we need to make very rapid > progress to avoid a crisis. Do we really believe that GDPR and HIPAA are > the future or are they just the camel's nose under a very shaky tent? > > Adrian > > On Fri, Sep 2, 2016 at 8:05 PM, James Hazard < > james.g.hazard@gmail.com> wrote: > >> Great work! >> >> As we considered "consent" vs other words in the conversation >> today, the GDPR's vocabulary seemed important, because it is likely to have >> great influence on privacy, in Europe and outside. >> http://www.commonaccord.org/index.php?action=doc&fi >> le=/Wx/eu/europa/eur-lex/GDPR/Comment/Consent/0.md >> >> A thought occurred to me - what if privacy policies and similar >> agreements relating to privacy mapped to the organization of provisions of >> the GDPR and reused, to the extent reasonable, the vocabulary of the GDPR. >> This would provide a base for a common taxonomy. The taxonomy would prove >> inadequate or undesirable, at least in detail, in many circumstances, but >> it is an influential starting place. >> >> Some time ago, I played with this notion in connection with the >> CPBR - the proposed US Consumer Privacy Bill of Rights. Like the GDPR, the >> CPBR calls for organizations (like Kantara?) to create charters that can be >> used by companies. I played out the idea as a privacy policy that >> referenced a charter, which in turn mapped to (was mostly made from) the >> CPBR. The resulting privacy policy is goofy, but it demonstrates a >> chain-of-text that connects all the layers of the conversation. >> >> http://www.commonaccord.org/index.php?action=list&file=Wx/go >> v/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ >> >> The GDPR has the additional advantage of being quite complete, >> actually enacted, available in many languages, etc. >> http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu >> /europa/eur-lex/GDPR/Form/0.md#Article.Sec >> >> On Fri, Sep 2, 2016 at 3:43 PM, Eve Maler <eve@xmlgrrl.com> wrote: >> >>> http://kantarainitiative.org/confluence/display/uma/UMA+lega >>> l+subgroup+notes#UMAlegalsubgroupnotes-2016-09-02 >>> 2016-09-02 >>> >>> - Working session on User-Managed Access (UMA) in Contractual >>> and Regulatory Contexts >>> <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHKQ-qNgNxgQjkzqod7Otto/edit?usp=sharing> >>> - Eve will try to press ahead with lots of editing AIs >>> prior to the call >>> - Adrian and Kathleen have sent various suggestions in >>> list/private email in the last month we should review >>> >>> Attending: Eve, Kathleen, Ann, John W, Mary, Jim >>> >>> We did a ton of work in the document. >>> >>> If you haven't seen it, the latest version of the slides with the >>> "legal use cases" is here >>> <http://www.slideshare.net/ForgeRock/usermanaged-access-why-and-how-access-control-in-digital-contract-contexts>. >>> Please feel free to share it. >>> >>> See also Jim's CommonAccord capture of the GDPR >>> <http://www.commonaccord.org/index.php?action=doc&file=/Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.4.11.sec> >>> . >>> >>> >>> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: >>> @xmlgrrl >>> >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA@kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> > > > -- > > Adrian Gropper MD > > PROTECT YOUR FUTURE - RESTORE Health Privacy! > HELP us fight for the right to control personal health data. > DONATE:http://patientprivacyrights.org/donate-2/ > > _______________________________________________ > WG-UMA mailing list > WG-UMA@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > >

-- @commonaccord

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE:http://patientprivacyrights.org/donate-2/

-- @commonaccord

-- @commonaccord

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.

-- @commonaccord