If the goal is transparency and the affliction of the powerful to comfort the afflicted, then it seems that a publicly distributed and inspectable ledger would have a role to play. If the goal is privacy and anonymity, then efficiently managing large numbers of entries may be counterproductive and large latency and search inefficiency becomes a feature. Just chumming the waters…. Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john@wunderlich.ca On 3 August 2016 at 10:08, James Hazard <james.g.hazard@gmail.com> wrote:

Though "Blockchain" is in the title of this discussion group, it need not be in all of the solutions. "Blockchains" have large privacy and data security challenges built into maintaining consensus on the state of the ledger (database). Most real life situations have available a range of alternative means of validating the state of the ledger. For instance, a regulator.

So, we might view it as a bug, rather than a feature, if a "smart contract" solution requires execution on a blockchain.

Organizations and humans will want to be able to efficiently manage large numbers of ledger entries, in efficient databases (SQL, graph, IPFS), not blockchains. They will need to be able to run the smart contracts on those other platforms.

Data replication should be minimized, and temporary to the extent possible. This will, I think, also be required by GDPR.

The necessary point of agreement, the waist of the Zittrain hourglass, is very small - a format for ledger entries. CommonAccord asserts (I assert on its behalf) that the key to this is ... key/values, a way of resolving references, and inheritance. For good reasons, JSON is a likely to be the most common "punctuation" (Eve's word) for exchange of ledger entries. Our current rendering engine uses plain text and carriage returns. That is the lightest "punctuation" and may be the best for collaboration on big texts, notably for collaboration among lawyers and regulators on Github. It closely parallels the presentation of software source code. But this barely matters. What matters is a common approach to linking and inheritance.

On Wed, Aug 3, 2016 at 6:53 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Domenico;

As soon as the use case makes Alice's role that of a "Citizen" a whole raft of non-technical issues arise that should be addressed. How do you implement privacy protection into the architecture to avoid abuse by authoritarian regimes? If I think of all the cases where I'm asked to present government issued ID as proof of identity, and then ask, "Would it be a good thing if there was an permanent audit trail available to the government (any state agency) of all those interactions?"

I would restate your problem definition to see if we can design a wide identity ecosystem use case for managing citizen identities that enables (or better, only works if) citizens control their own identities.

(PS, see my signature block below, apropos of this issue)

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: Domenico Catalano <domenico.catalano@oracle.com> Sent: Wednesday, August 3, 2016 4:47 AM Subject: [DG-BSC] Blockstack identity services To: <dg-bsc@kantarainitiative.org>

Hi all,

maybe, you already know blockstack id technology for identity services, at blockstack.org <https://blockstack.org/docs/how-blockstack-works>

I think it’s quite useful for investigation and for defining use cases.

I was wondering whether we can provide a wide identity ecosystem use case for managing citizen identities.

Consider the following high level use case:

- The Citizen is identified by a Blockchain-ready Registry. - The Citizen requests to register with the Registry through a specific mobile app, which provides the necessary cryptographic key pairs with which the request is signed. - The Registry includes the request in the blockchain which is distributed among the nodes, as smart contract. - The mobile app and the cryptographic keys are now able to provides strong authentication mechanisms for citizen online access.

Citizen Identity can be enriched through the blockchain nodes (special nodes) interactions which provide attribute/profile attestation.

I hope it’s useful for further discussions.

Thanks Domenico

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

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

Hi Patrick, Great message. My father, who taught and practiced law, said the conversation should start with where you want to be. That seems to me to be more or less the P2P, PDS, MIT Connection Science vision. Each of us has our formal existence in databases under our control. Each of our records interoperates with all of our other records. We can store them at trust providers (e.g., banks) like we do with cash, and carry only what we need. An app, on phones and anywhere else we want it, allows us to transact with anyone - or any thing - else. To have different accounts for different roles. To have our information be only in the places that it must be to interact with the network. This has lots of parallels with email. The rules of engagement - the stuff that good lawyers put into documents for smart clients - is clear, fast, free. We navigate bureaucracy - and weigh the trade-offs - like we use Waze. In this view, blockchains are a tool for syncing records. So are IPFS and Interledger, and git, and all of the existing or new payment systems. Blockchains, with their methods for peer-based consensus on the state of the record and their anti-double spend appear useful - necessary - when there is no 3rd party trust provider - or the trust provider can't be reached. The IoT is full of those use cases. This - which just came across my twitter feed - seems quite good at exploring when a blockchain is necessary (though perhaps the thinking does not include the possibility of a multiplicity of blockchains, used like email threads). https://www.linkedin.com/pulse/when-do-you-need-blockchain-decision-models-s... (Is the reference to our Bart Suichies?). All this is independent of, but a powerful driving force for, my project and concern, bringing the dynamic of open source collaboration to the negotiation and codification of legal forms. Codification of boilerplate (@gendal's "prose") indirectly codifies the law, and enables a decentralized Waze approach to bureaucracy. All good, Jim On Thu, Aug 4, 2016 at 6:09 AM, Patrick Curry <patrick.curry@bbfa.info> wrote:

Hi James,

Interesting. Good discussion, thanks. I offer a few comments.

Block chain refers to a specific, defined technology. Blockchain is a trademark.

Do we mean solutions or requirements? Are the solutions technology specific or general solutions to a business problem, where a block chain may feature as part of the solution set?

If we replace Proof of Work with PKI Federation, which is attractive & desirable in many situations, do we still have a block chain? My block chain colleagues believe that we still do, and there is an ongoing discussion about how PoW might be measured to achieve some sort of LoA that could map, in policy terms, to PKI and create a basis for for BC - PKI federation.

The voting process presents several complexities, some of which could be addressed by an underlying trust fabric. There hasn’t been much discussion about this yet, but it will definitely be moving there later this year as the UK government has just approved its first BC provider to be listed in a catalogue service available to all UK gov organisations.

A feature of BCs being used in regulated settings is that the regulator (regulators in many cases, particularly internationally) requires to have a voting node and so gets to see all traffic. Regulators haven’t woken up to this yet, but I am expecting to see them require the development of rulesets that are embedded in the process in the BC with decision authority (signature), i.e. a smart contract. I don’t understand why this would be a bug. A feature or a factor, yes.

Ref data management, the smart contract is a feature of permissioned block chains because of how the cryptography works. It’s hard to see how this functionality could be replicated easily in other existing technologies. Instead, what is beginning to happen is that companies link their ERP etc to the block chain. The ERP provides the internal business functionality and logic, the block chain DLT provides the external interoperability & contract integrity. The smart contract runs on the chain, not on in the enterprise app. This satisfies the supply chain requirements where a centralised enterprise solution would/does not.

Agree about data replication. Depending on the nature of the business requirement and use cases, data minimisation is one of the privacy principles. Proofs of concept on some Zero Knowledge Proof mechanisms have been completed and a couple are moving to bigger pilots. ZKP and other anonymised attribute assurance mechanisms are attractive and suitable options for block chain privacy requirements.

Interesting that you mention Zittrain. His work on trusted intermediaries has come up in international discussions of lead industries, law enforcement and govs, as a way to address policy collisions on public safety and privacy. The discussions are more about encryption and key management; block chains haven’t yet been discussed, but they might be. I agree about JSON. I’d be interested in knowing more about your and Eve’s work in this area. is there anything you can share?

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 3 Aug 2016, at 15:08, James Hazard <james.g.hazard@gmail.com> wrote:

Though "Blockchain" is in the title of this discussion group, it need not be in all of the solutions. "Blockchains" have large privacy and data security challenges built into maintaining consensus on the state of the ledger (database). Most real life situations have available a range of alternative means of validating the state of the ledger. For instance, a regulator.

So, we might view it as a bug, rather than a feature, if a "smart contract" solution requires execution on a blockchain.

Organizations and humans will want to be able to efficiently manage large numbers of ledger entries, in efficient databases (SQL, graph, IPFS), not blockchains. They will need to be able to run the smart contracts on those other platforms.

Data replication should be minimized, and temporary to the extent possible. This will, I think, also be required by GDPR.

The necessary point of agreement, the waist of the Zittrain hourglass, is very small - a format for ledger entries. CommonAccord asserts (I assert on its behalf) that the key to this is ... key/values, a way of resolving references, and inheritance. For good reasons, JSON is a likely to be the most common "punctuation" (Eve's word) for exchange of ledger entries. Our current rendering engine uses plain text and carriage returns. That is the lightest "punctuation" and may be the best for collaboration on big texts, notably for collaboration among lawyers and regulators on Github. It closely parallels the presentation of software source code. But this barely matters. What matters is a common approach to linking and inheritance.

On Wed, Aug 3, 2016 at 6:53 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Domenico;

As soon as the use case makes Alice's role that of a "Citizen" a whole raft of non-technical issues arise that should be addressed. How do you implement privacy protection into the architecture to avoid abuse by authoritarian regimes? If I think of all the cases where I'm asked to present government issued ID as proof of identity, and then ask, "Would it be a good thing if there was an permanent audit trail available to the government (any state agency) of all those interactions?"

I would restate your problem definition to see if we can design a wide identity ecosystem use case for managing citizen identities that enables (or better, only works if) citizens control their own identities.

(PS, see my signature block below, apropos of this issue)

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: Domenico Catalano <domenico.catalano@oracle.com> Sent: Wednesday, August 3, 2016 4:47 AM Subject: [DG-BSC] Blockstack identity services To: <dg-bsc@kantarainitiative.org>

Hi all,

maybe, you already know blockstack id technology for identity services, at blockstack.org <https://blockstack.org/docs/how-blockstack-works>

I think it’s quite useful for investigation and for defining use cases.

I was wondering whether we can provide a wide identity ecosystem use case for managing citizen identities.

Consider the following high level use case:

- The Citizen is identified by a Blockchain-ready Registry. - The Citizen requests to register with the Registry through a specific mobile app, which provides the necessary cryptographic key pairs with which the request is signed. - The Registry includes the request in the blockchain which is distributed among the nodes, as smart contract. - The mobile app and the cryptographic keys are now able to provides strong authentication mechanisms for citizen online access.

Citizen Identity can be enriched through the blockchain nodes (special nodes) interactions which provide attribute/profile attestation.

I hope it’s useful for further discussions.

Thanks Domenico

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

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

-- @commonaccord