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