(semi-inline)

Consent Receipts - Yes, perfect.  We don't yet have a JSON parser, but want one.  I agree there is a fit and the GDPR is a driving force.  

Data Sharing Agreements
​ - I've done a number of these in different contexts.  An interesting setting is the European "Model Clauses" Agreements.  These have the advantage of being well-known to the regulators and available in 20+ languages.  I did a number of them on a shared outline - 
http://www.commonaccord.org/index.php?action=list&file=Wx/eu/europa/eur-lex/Privacy/ModelClauses/Demo/.

​Terms of Use - There are a number of these, but none really stands out. I'd love leads on a form that has some traction.   

Web Privacy Notices & Short Notice - Yes, systemic provenance could facilitate clarity.  This "policy" is derived from the "Consumer Privacy Bill of Rights."  The Bill calls for organizations to create conforming charters and for companies to be transparent with users.  The "policy" references a charter which adapts the Bill.  While the policy doesn't actually make much sense, it shows a chain of text from legislation through collaboration, to a company and then to the citizen.  
http://www.commonaccord.org/index.php?action=doc&file=Dx/Acme/03-Policies/01-Privacy_v0.md




On Mon, Aug 1, 2016 at 7:20 PM, John Wunderlich <john@wunderlich.ca> wrote:
James;

With that ‘scope’ in my world there are a number of types documents that might  be amenable to this treatment (and I know you have time for none of this. Just adding it to the wish list-)

Consent Receipts (for transparency and accountability between data subject and data controller)
The standard we are working on includes a plain language (human readable) receipt and an optional underlying data transport model in JSON. If it gets any traction, there could be jurisdictions (GDPR cough cough) where having it in a more rigorously legal format might have applications.

Data Sharing Agreements
​ (for agreeing how two or more entities may share and use data)​
They are either two party agreements where lawyers on both sides go (expensively) to town, or are contracts of adhesion that get frozen in time because of the difficulty of re-opening the discussions between all the parties.

​Terms of Use
​Insert contracts of adhesion rant here. Would love to see an web site terms and user submitted terms using a standard common accord lexicon. Would enable, I should think, an interesting handshake between browser and server to see if each qualify for the other!​


 Web Privacy Notices & Short Notice
Usually erroneously ​labelled privacy policies, perhaps common accord tools would enable what ’nutrition label
approaches failed to accomplish.​
​​


Sincerely,
John Wunderlich
@PrivacyCDN

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


On 1 August 2016 at 18:11, James Hazard <james.g.hazard@gmail.com> wrote:
Thanks for climbing the learning curve. 

Yes a person can have multiple roles.  

Think of the "scope" of CommonAccord as being anything that someone _might_ want to put in a legal document - a consent, guideline, contract, protocol, etc.  Currently, legal documents often paint access rights with a broad brush.  They tend to be written lawyers, who may have only rough familiarity with the business operations, and they tend to be written for organizations who receive the data and want flexibility.  Also, there tends to be an assumption that messaging between the data holders and the subject is cumbersome, so broad authority is required to deal with eventualities.  

When a source-based approach is used, particularly in connection with smart contracts, legal texts can be much more closely tailored, and interactions cheaper.  

So the rough answer is that the scope includes anything that a lawyer might write or review, that a regulator might insist on, or that a "subject" might want to know. 



   

On Mon, Aug 1, 2016 at 5:55 PM, John Wunderlich <john@wunderlich.ca> wrote:
I’m still climbing the learning curve on common accord, but it looks good to me. I’m assuming that a natural person can have multiple roles and that resolving conflict between role re: differential access to data and what can be done with it is out of scope of common accord? 


Sincerely,
John Wunderlich
@PrivacyCDN

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


On 1 August 2016 at 16:52, James Hazard <james.g.hazard@gmail.com> wrote:
Hi John, 

I looked at your use case document again and made a few conforming changes - Carol is a Physician care-giver and Dan is a Local Investigator.  

Changes were made in the underlying docs - not as a patch.  Result remains here:

The commit showing the changes is here:

Jim


On Mon, Aug 1, 2016 at 12:57 PM, Eve Maler <eve.maler@forgerock.com> wrote:
Fascinating. The paper by Annalies Moens in particular, whom I met at EIC, seems the most pithy and accurate (tell me if you think I'm off-base) -- and Patrick, your writeup in response to the papers in this thread contains a heck of a lot of good nuggets. :-) I wonder if we could leverage some of this content for our report, with appropriate citations.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to Sydney, London, and Paris!


On Sat, Jul 30, 2016 at 7:30 PM, John Wunderlich <john@wunderlich.ca> wrote:
Patrick;

My forwarding of the content shouldn’t be construed as endorsement or agreement with the content.. I shared the pieces because they will be, for many privacy professionals, the extent of what they know about blockchain for good or for ill.

Thanks for detailed response and I stand informed or in agreement with it (at least those parts that didn’t go over my head). With respect to this discussion group, I think that key takeaway are your points about how block chains need high assurance federated identity and access management as well as trusted attributes from authoritative sources. This strikes me as a bit of a recursive need (chicken and egg if you will) since it seems likely that high assurance federated identity will need a distributed ledger.

Resolving the nature of this recursion and established the requirements or the nature of a solution would be a great outcome from this discussion group.


Sincerely,
John Wunderlich
@PrivacyCDN

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


On 28 July 2016 at 15:00, Patrick Curry <patrick.curry@bbfa.info> wrote:
Hi John,

Thank you for the articles!  There’s a lot of good stuff in them.

However, I don’t agree with some of the points and there is a bit of confusion between Bitcoin and block chains across the documents as a whole (e.g definition of Bitcoin). 

There is a lot happening around block chains in the bigger picture, particularly in parts of Europe and Asia, and much less so in the USA - although I am sure this will change soon.

As someone involved in many aspects of blockchains and DLTs, and as a co-author of the UK gov report you mentioned (which was written for politicians and has stimulated political action!), I would comment that:
  • Within the IGF, block chains are seen as potentially the most disruptive technology impacting the future of the Internet.  New secure mobile technologies will magnify this impact.
  • There is block chain activity in nearly every sector and in a small, but increasing, number of government organisations and international organisations, including in refugee camps.
  • Meantime, new Block chain 2.0 technologies are emerging that are more tailored to meeting specific and diverse needs much more efficiently.  Block chain as a platform is not far away.  (I can provide details next week after a UK gov announcement next monday). 
  • Financial use of block chains is primarily for payments (customer and inter-bank), clearing, investments, trading and settlements.   The banks are only just waking up to the wider use of block chains to support new services.
  • Bitcoin
    • Society is very confused about Bitcoin, and whether it is good or bad.  
    • Bitcoin benefitted from first mover advantage, but it suffers from the historic inevitability that any economic system without adequate governance will collapse when those that can, abuse others too much.  Hence the drive to introduce much more governance into cryptocurrencies and have suitable mechanisms in the underlying block chains.  Practically, some of the banks have been looking at how to establish “trusted Bitcoin” i.e. to put a cryptographically bound wrapper around the Bitcoin transaction and the provenance/traceability trail, which would more normally be met in a permissioned chain.
    • Bitcoin has been a contributory factor to a significant rise in cyber crime, which has increased by 300% since 2011, and last year stood at $7.4 trl according to Red Dragon Rising and agencies.  Hence there is likely to be a move by authorities to take down untrusted Bitcoin in the future.  Much of this blurs with dark web and anonymisation/privacy networks, which KI probably ought to understand, if only to appreciate the implications for trust, IAWG etc. 
    • Bitcoin is slow and suffers from scalability problems, although temporary remedies are being suggested.  More efficient and effective solutions could arise out of leading startups or the R3 collaborative group of 43 banks which is exploring new block chain and cryptocurrency possibilities.
  • There are many other uses of block chains that we can discuss.
  • Very importantly, the main value of DLTs and permissioned block chains is where they hold valuable or sensitive information that is distributed across a great many organisations.  Such block chains cannot realistically function without:
    • Federated identity and access management at High Assurance (LoA 3+)
    • Trusted attributes from authoritative sources.  As all entities and attributes in cyberspace bind to an organisation, so trusted registers for organisations fit for digital economies and societies, are becoming a major issue in many nations, including USA.  New national and international legislation for traceability of people and things is increasing the pressure.
  • Those nations and some industries that already have a standards-based, federated identity management are recognising that PKI federation will become very important to the future use of block chains, because:
    • Block chains require PKI to provide the recordset or “block” binding into a chain
    • Permissioned chains, particularly with smart contracts, require federated authentication, signature and encryption.
    • Crucially, PKI federation could replace the Proof of Work, dramatically reducing the operating cost and risks of the chain and significantly increasing its speed, scale, reliability and assurance. The advent of a new X.509 standard that includes certificate whitelisting (goodbye Certificate Revocation Lists) would enhance this.  Same goes for node operations.
  • Several international projects, such as EU MAPPING, are tracking developments and factoring these into the drafting of new legal instruments that may result in regulations, directives and laws, particularly around privacy and surveillance.  Law enforcement and security & intel services are also involved, as work continues to ensure that block chains evolve consistent with fundamental human rights.
  • Finally, Australia has initiated a discussion in ISO about the possibility of a new Sub Committee for Block Chains, which touches/overlaps with the work of several other SCs, notably SC27 which meets in Abu Dhabi in late Oct.  The UK has replied with proposed improvements and we await to see what happens.  Meantime, in some nations, local initiatives to develop standards are being corralled to feed into international standardisation efforts.  

There are a few collaborative groups operating in London, with international participation, shaping developments and communicating/coordinating.  Some governments are involved.  The possibility of the first Policy Management Authority for block chains, with a Common Policy, is being considered, to anticipate and feed into current operations and future standards - and all points in between.  Maybe some KI members could join in.  Or some of their members join KI.

How KI might fit into all of this (and more),  I don’t know, but I have some ideas where it could acquire a USP.  I welcome the opportunity to talk.

regards,

Patrick

Patrick Curry
Director

British Business Federation Authority - BBFA Ltd
M: +44 786 024 9074
T:   +44 1980 620606
patrick.curry@bbfa.info
www.bbfa.info – a not-for-profit, self-regulating body   



On 28 Jul 2016, at 18:33, John Wunderlich <john@wunderlich.ca> wrote:

The IAPP (International Association of Privacy Professionals) has published a number of small pieces for privacy professionals about blockchain on its web site and newsletters. I've attached a representative sample for your edification



Sincerely,
John Wunderlich
@PrivacyCDN

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



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.
<A Privacy Engineer’s Analysis of Bitcoin.pdf><Blockchain and big data privacy in healthcare.pdf><Unravelling the mystery of blockchain – Should privacy professionals be concerned_.pdf>_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc




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.

_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc



_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc




--
@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



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