Thomas, yes.  And I intend a very shallow meaning for "smart contracts," along the lines of our Smart Contracts Description Language paper for the W3 last year.  A bit of code that effectuates some part of a transacting function, independent of the platform.  Complemented by "prose objects" in the Ricardian triple of parameters, code and prose.

Our focus remains developing legal prose objects and advocating for a "Center for Decentralized Governance."  

 

   

On Sun, Jun 4, 2017 at 7:07 AM, Thomas Hardjono <hardjono@mit.edu> wrote:

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



--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

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




--
@commonaccord

--

@commonaccord

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