Thomas wrote:

"One thing I'm interested in looking at is "chained" or cascading smart-contracts (where sc-A triggers sc-B and then C and so on) -- and the various possible deadlocks or loops it can create. Recall that one of the challenges of the early internet was coming with loop-free or loop-detecting routing protocols (thinks of the IS-IS protocol and the OSPF protocol for local routing)."

My response to Thomas indulges in some bits of esoterica, and might not be of interest to the entire group. However, thinking about "chains" "loops" and other such relationship forms as both potential challenges and as features that can be recruited into service as intentional, helpful structural constraints on interrelated systems (whether smart contracts, or nerve cells or Nucleic acids - Notably all of which are information carrying systems) is, I think, absolutely critical to achieving distributed scaled systems for information, so I am sharing the reply with the group.

My apologies in advance if these points seem even more "out there" than my usual contributions. Consider, however, that these are all examples taken from various other types of "information systems" and therefore which might provide evidence of some intrinsic structural approaches to information governance, etc.

On the issue of chained contracts and loops, etc., among the points we should discuss (in the appropriate forum!) are:

What are the implications of analyzing the 2008 financial "break" as the result of cascading "cross default" provisions of various financial agreements? What are the contractual and market mechanisms that might be applied to moderate those cascades? What mechanisms are deployed to moderate positive feedback in other contexts?
What is the nature of feedback (whether positive and/or negative) in propagating and/or mitigating dynamic chains? How might certain loop structures control chain propagation (like drilling a hole in at the end of a crack in a glass window).
How might loops be purposefully constructed and introduced into help initiate "risk-mitigation-by-design" in systems. There are multiple examples of "loops" that manifest across different vectors in different domains to prevent altered configurations that can be harmful to system "normal" operation. Examples include:
1. (a) chemical loops - the positive and negative relationships among neurotransmitters at synapses and their various "excitory" and "inhibitory" effects interactions.
2. (b) see related issues of chemical "bistability" such as http://bmcsystbiol.biomedcentral.com/articles/10.1186/1752-0509-3-90http://bmcsystbiol.biomedcentral.com/articles/10.1186/1752-0509-3-90 . How might intentional loops help a system to acquire one of the designed "stable states" for which it is developed?
3. (c) physical loops - DNA, RNA and proteins - Loop structures prevent lots of genetic (and epigenetic) mischief in Nucleic Acids. Various harmful mutations, etc. that could result in harmful configurations for DNA and RNA and also of secondary and tertiary folding structures of proteins are constrained by various forms of loop structures, etc. See, e.g., "RNA/DNA Hairpin loop structures" at https://en.wikipedia.org/wiki/Stem-loop
4. (d) contractual loops - contracts and laws provide various loop structures that help to introduce "strain relief" into systems. Consider such devices as "cure periods" for contract default as temporal "loops" introduced as "strain relief in contract duties/rights contexts.
This list is just off the top. I am certain that further reflection will reveal other structures in which loops and chains play a pathological and/or palliative role in systems. Where distributed systems rely on each "node" being "programmed" with the same narrative (aka "singing off the same song sheet"), loop and chain structures embedded in the architecture can help to assure reliability-by-default.

Good stuff.

Kind regards,

Scott

Scott L. David

Director of Policy

Center for Information Assurance and Cybersecurity

University of Washington - Applied Physics Laboratory

w- 206-897-1466

m- 206-715-0859

Tw - @ScottLDavid

From: Thomas Hardjono <hardjono@mit.edu>
Sent: Sunday, June 4, 2017 6:26 PM
To: sldavid; James Hazard; Adrian Gropper
Cc: wg-uma@kantarainitiative.org; eve.maler@forgerock.com; hardjono@media.mit.edu
Subject: RE: [WG-UMA] New paper on Identity, Data and next-gen Federation

Scott,

Very insightful, as usual :-)

>>> query whether the AI and bots "use" the smart contracts or,
>>> instead, do the smart contracts actually "compose/comprise"
>>> the distributed AI (and "good bot") system?
>>> In other words, will smart contracts be the "synapses" of AI/SI systems?

It could be. Also, just as they are different hierarchies and importance-levels to biological synapses, these could be different levels or hierarchies of smart-contracts. That is, smart-contracts (bots) to manage other smart-contracts (bots).

What might be different with smart-contracts (at least the way we understand it and define today) is that (a) all node must have equal access to executing a smart-contract (ie. each node can load the same smart-contract) and (b) some consensus agreement protocol is used to arrive a stable state (agreed state) among the nodes executing the smart-contract.

I don't know if biological "synapses" use such mechanisms (i.e. actually doing agreement among "synapses").

>>> Stated otherwise, are standard smart contracts a way of hybridizing
>>> AI with SI (see below on "SI" concept), where the synthesis of
>>> multiple instantiations of the identical smart contracts across nodes
>>> (a la "distributed ledger") enables a form of suppression (self-regulation?)
>>> of errant smart contract application that might reflect intentional or
>>> accidental out-of-bounds activity on a network?

So the logic to effect suppression or self-regulation must be part the consensus protocol among the nodes.

One thing I'm interested in looking at is "chained" or cascading smart-contracts (where sc-A triggers sc-B and then C and so on) -- and the various possible deadlocks or loops it can create. Recall that one of the challenges of the early internet was coming with loop-free or loop-detecting routing protocols (thinks of the IS-IS protocol and the OSPF protocol for local routing).

/thomas/

________________________________________
From: sldavid [sldavid@uw.edu]
Sent: Sunday, June 04, 2017 12:53 PM
To: Thomas Hardjono; James Hazard; Adrian Gropper
Cc: wg-uma@kantarainitiative.org; eve.maler@forgerock.com; hardjono@media.mit.edu
Subject: Re: [WG-UMA] New paper on Identity, Data and next-gen Federation

HI folks - I am coming into this particular thread late, so I may be missing the initial point. Begging folks' indulgence if this is a "fork"(I hope it is not) - on the prior couple of points, query whether the AI and bots "use" the smart contracts or, instead, do the smart contracts actually "compose/comprise" the distributed AI (and "good bot") system? In other words, will smart contracts be the "synapses" of AI/SI systems?

Stated otherwise, are standard smart contracts a way of hybridizing AI with SI (see below on "SI" concept), where the synthesis of multiple instantiations of the identical smart contracts across nodes (a la "distributed ledger") enables a form of suppression (self-regulation?) of errant smart contract application that might reflect intentional or accidental out-of-bounds activity on a network?

Might standard contracts be used to establish a form of system "self" (albeit an intangible form of system "self") that can distinguish system "other" (like learned immunity systems), and police (and enforce) terms to reify the "self" that is reflective of the optimal system function (at least optimal as programmed in the smart contracts!)

Are P2P networks a form of "SI" (Synthetic Intelligence) that is synthesized into a form of system intelligence that is greater than the sum of its parts, and which reflects an additional potential architecture for distributed AI?

Part of our challenge in these sorts of distributed intelligence settings is , from a graph theory perspective, to get each "node" to be singing off the same song sheet. When those nodes are people, narratives (such as from religion, politics, social norms, economic incentives, ethical constructions, etc.) are the "song sheet/programming" of the nodes.

When those nodes are commercial organizations, then economic goals (as required by their respective state laws of formation, articles, bylaws and contracts) and regulatory constraints are the "song sheet/programming" of the nodes.

As an aside, a fundamental challenge of the Internet is that it is a shared infrastructure among groups that are singing off different song sheets. For example, when people are pursuing advice online about a social/emotional challenge (for example), they are also (below their awareness) sharing the communication space (and the communication) with commercial actors which (under current TOU/TOS arrangements, etc.) are able to access their communication and hence glean insight into that person's behavior/motivations and sell them some "placebo/face cream/whatever" that is offered to help fill the voids (both epidermic and existential, etc.) which fulfills the commercial goal of generating revenue, etc. Smart contracts will provide a mechanism for us to calibrate, normalize (and analyze, and improve) the balance of "information arbitrage" that is currently skewed in these shared spaces. Those imbalances are currently an artifact of yesterday's power relationships and its technical and legal embodiment in the Internet.

Based on the foregoing observations/quasi-rant, it seems likely that smart contracts will find initial deployment in the simplest (lowest risk) contract settings - those with few input variables (called "conditions" in law) and applied in innocuous settings.

For example, is a useful model of these "distributed smart contract" deployments the old (distributed) mechanical parking meter system, where each parking meter is built/programmed to register a certain amount of time for a given payment, and is constrained in its pre-programmed flexibility. The parking meter system, in gross, represents a form of mechanistic "neighborhood watch," but not against various crimes, but only the specific violation of unpaid parking. Simple, few variables, innocuous - reliable.

Standard contracts (such as the fedex(tm) standard shipping terms, or the standard forms of PCI-DSS conformant credit card terms) create an intrinsic distributed (albeit intangible) risk-sharing topology that is reified with the serial agreements of its participants. In other words, every contracting party becomes an interested party in the reliability of the system when they sign up and hence depend on that system. This is particularly so in executory contract settings, or those with minimal signing ceremonies (i.e., "click to accept"), the recruitment of participants into the constraints of the agreement is made as simple as possible (so as not to distract the raw system recruit from their enthusiastic information-seeking behavior!)

All of this is intended to convey the suggestion that there are strategies that can help to address the (appropriately) perceived dangers of "smart contracts" being enforced in inappropriate settings, or despite the failure of party expectations. Settings in which "Dumb contracts" (like mechanical parking meters, shipping agreements, etc.,) are already successfully applied at large scales may provide favorable piloting circumstances.

The constraint of the system is a source of security, since it means that a parking meter cannot, for example, be accidentally or intentionally reprogrammed to do less innocuous things. Can smart contracts be "hardened" against such reprogramming? Perhaps (in the alternative) the immediate "externality" of the smart contract can detect and dampen functional drift of a given smart contract? One similar idea that we have been fussing with in some security discussions is a P2P "neighborhood watch" AMONG IoT devices. Distributed solutions for distributed challenges.

But I digress. . .

Kind regards,

Scott

Scott L. David

Director of Policy

Center for Information Assurance and Cybersecurity

University of Washington - Applied Physics Laboratory

w- 206-897-1466

m- 206-715-0859

Tw - @ScottLDavid

________________________________
From: wg-uma-bounces@kantarainitiative.org <wg-uma-bounces@kantarainitiative.org> on behalf of Thomas Hardjono <hardjono@mit.edu>
Sent: Sunday, June 4, 2017 7:07 AM
To: James Hazard; Adrian Gropper
Cc: wg-uma@kantarainitiative.org; eve.maler@forgerock.com; hardjono@media.mit.edu
Subject: Re: [WG-UMA] New paper on Identity, Data and next-gen Federation

Thanks Jim,

So in the paper I purposely omitted any mention of smart-contracts (too distracting).

We have a small project on how to make the "algorithm" (think simple SQL statement) into a smart-contract (think Ethreum).

The algorithm-smart-contract is triggered by the caller (querier) and it has to be parameterized (e.g. input the public keys of the querier and the data-repository; payments, etc).

So this is pointing towards a future model for data-markets, where these algorithm-smart-contracts are available on many node of the P2P network, and anyone can use them (with payment of course).

Not to be too hyperbolic, but think of futuristic "AI and bots" that make use of these various algorithm-smart-contracts.

/thomas/

________________________________________
From: wg-uma-bounces@kantarainitiative.org [wg-uma-bounces@kantarainitiative.org] on behalf of James Hazard [james.g.hazard@gmail.com]
Sent: Sunday, June 04, 2017 9:31 AM
To: Adrian Gropper
Cc: wg-uma@kantarainitiative.org; eve.maler@forgerock.com; hardjono@media.mit.edu
Subject: Re: [WG-UMA] New paper on Identity, Data and next-gen Federation

Great to see this discussion.

Some time ago, I did a demo of the sequence of events in writing and clearing a paper check - right at the boundary between a contract and a payment. It shows each step as a record that references other records. Some of the other records define the meaning of a step, in both text and automation. The automation is expressed in (fake) granular bits of code, referenced by their hash.

This would allow curation of granular bits of automation ("smart contracts" in a broad sense). Those could be validated by an organization or standards body.

The demo was made with the pending EU PSD2 in mind, as a way for financial institutions to collaborate on APIs. But the principle is broadly applicable to transacting in general.

http://www.commonaccord.org/index.php?action=doc&file=bqc/fr/bnpp/a5we/Account/Check/00001/06-Accept.md
(Click on "Source" and follow links.)

On Sun, Jun 4, 2017 at 5:33 AM, Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
Please, let's avoid applying the word farming to people. The Matrix will be upon us soon enough.

Adrian

On Sun, Jun 4, 2017 at 8:24 AM, Mark Lizar <mark@openconsent.com<mailto:mark@openconsent.com>> wrote:
Trust Farmer, what a great term !

Use of RAW personal data is clearly a barrier for trusted service development and this makes a lot of sense.

OPAL provides an economic, high value information argument. It also helps to illuminate a landscape for competitive service development with personal data that people control or co-manage. (Which is what I like the most:)

- Mark

> On 4 Jun 2017, at 02:44, Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu>> wrote:
>
>
> Thanks Mark,
>
> An easy way to illustrate the "algorithm" is to think of an SQL statement (e.g. "compute average income of people living in Cambridge MA"). I send you the SQL statement, then you compute it in your back-end data repo (behind you firewalls), and then return the result to me.
>
> Assuming a community of Data Providers could get into a consortium governed by a trust farmer, the could collectively come-up with say 20 of these SQL queries (vetted of course).
>
> The point of the paper is that the barrier to sharing data (raw data) is getting impossible to overcome (think GDPR), and if data-rich institutions (i.e. Banks) want to play in the identity space by monetizing their data then OPAL provides a practical/palatable approach.
>
> From the consent side, the user needs the ability to say: "I know my data is part of data-repo-X, and I give consent for algorithm A to be executed on data-repo-X".
>
> The data-repository also needs a recipe to prove the use had given consent.
>
> /thomas/
>
>
>
>
> ________________________________________
> From: Mark Lizar [mark@openconsent.com<mailto:mark@openconsent.com>]
> Sent: Saturday, June 03, 2017 4:09 PM
> To: Thomas Hardjono
> Cc: wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org>; eve.maler@forgerock.com<mailto:eve.maler@forgerock.com>; hardjono@media.mit.edu<mailto:hardjono@media.mit.edu>
> Subject: Re: New paper on Identity, Data and next-gen Federation
>
> Hi Thomas,
>
> You made quick work of this wickedly hard problem :-). (To run with this a bit)
>
> This looks a lot like the consent to authorise pattern we have been discussing. Which I would define as the :
>
> 1. - purpose specification
> 2. - to consent permission scopes
> 3. - to privacy policy model clauses
> 4. - to UMA
> 5. - to contract policy clauses
> 6. - to permission
> 7. - to user control
>
> To make this sort of thing happen I have been working on the premise that a machine readable privacy policy, is configured with a purpose category that is defined with preference scopes (or a consent type that defined scopes and maybe also preference options) which then are associated with model privacy policy clauses.
>
> This then boils down into a consent to authorise privacy policy scope profile for UMA access, which would then be used to defines the permission scopes and the associated contract model clauses that enable people to manage and control their own information.
>
> At which point, the data subject could bring to the party their own license, which provides the model clauses, which match the aforementioned policies and defines how the preferences are set and managed.
>
> The whole policy model will link with the permission scopes and preferences to basically sort out all the old school policy issues that are gumming up the works currently.
>
> With the above framework in place,
>
> The algorithms could be defined by the purpose category (i.e. industry) configured by the consent to authorise profile, and then controlled by the individual with model clauses that delegate to trusted third party applications. This provides the higher order transparency and accountability needed - or perhaps ethics - which the user is ultimately the master controller of via a data services provider.
>
> It is conceivable that the user could bring their own algorithims, or have algorithims that police algorithims which is reminiscent of the original cop monkey pattern (if I am not mistaken)
>
>
>
> - Mark
>
>
> On 2 Jun 2017, at 16:03, Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu><mailto:hardjono@mit.edu<mailto:hardjono@mit.edu>>> wrote:
>
>
> Eve, Mark, UMA folks,
>
> This new paper (PDF) might be of some use in framing-up the next level of discussions regarding "identity" and "data" and how to"federate data".
>
> Its permanent link is here:
>
> http://arxiv.org/abs/1705.10880
>
> I'm thinking that the Claims-gathering flows in UMA and also the Consent-Receipts flows could use an "algorithm-identifier" value, effectively stating that "Alice consents to Algorithms X be run against her data set Y" (where the data-set lies in her private Resource Server).
>
>
> Best.
>
> /thomas/
> <open-algorithms-identity-federation-1705.10880.pdf>

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

WG-UMA -- This is the User Managed Access WG mail list.

kantarainitiative.org