[DG-BSC] IAPP views of blockchain

James Hazard james.g.hazard at gmail.com
Mon Aug 1 21:17:36 CDT 2016


(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 at 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 at wunderlich.ca
>
> On 1 August 2016 at 18:11, James Hazard <james.g.hazard at 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 at 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 at wunderlich.ca
>>>
>>> On 1 August 2016 at 16:52, James Hazard <james.g.hazard at 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:
>>>>
>>>> http://source.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/DG-BSC/HRC/Demo/Consent/v02-JW.md
>>>>
>>>> The commit showing the changes is here:
>>>>
>>>> https://github.com/CommonAccord/Cmacc-Source/commit/510fcf66e9b91c65235d0075d736cf65bad6b25d
>>>>
>>>> Jim
>>>>
>>>>
>>>> On Mon, Aug 1, 2016 at 12:57 PM, Eve Maler <eve.maler at 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
>>>>> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>>>>>
>>>>> On Sat, Jul 30, 2016 at 7:30 PM, John Wunderlich <john at 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 at wunderlich.ca
>>>>>>
>>>>>> On 28 July 2016 at 15:00, Patrick Curry <patrick.curry at 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 at bbfa.info
>>>>>>> www.bbfa.info – a not-for-profit, self-regulating body
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 28 Jul 2016, at 18:33, John Wunderlich <john at 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 at 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 at 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 at kantarainitiative.org
>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DG-BSC mailing list
>>>>> DG-BSC at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160801/3746f765/attachment-0001.html>


More information about the DG-BSC mailing list