We will be running a "Legal/Technical Integration" track at the MIT Media Lab's upcoming Personal Data and Trust Framework Hackathon to be held from January 28 through Feb 1st.   Specifically, concurrent design and agile development of applied MIT Model Rules (aka System Rules and contracts) and code for the OpenPDS software will be the anchor of this track, and we will specifically be focused on converging the "apps" management screen available to a user to see and possiblu revoke any OAuth 2.0 grants of access to their personal data with a new concept for the "Terms of Service" page for the PDS - in effect creating a new type of user managed apps and legal terms instrument.  This approach, and the related functions and flows, is called IAuth.  Wireframes, demo code and documentation with memoranda on this approach will be posted here in the coming days and will be provided all activity participants in this track. 

Update: The Event Page is: http://iauth.org/event/ (coming soon) and below is a video providing a general overview of the approach and the event:

Overview and Call for Participation:  http://youtu.be/ZCcGGUz4yb4

The current main entry for the related "apps" hack-a-thon event is available at: http://student.mit.edu/searchiap/iap-9289af8d3ad05bc3013ad1ab39810064.html

For more information on this legal track hack-a-thon, please contact Dazza Greenwood, at: http://ecitizen.mit.edu/contact

Initial thoughts on how deliberately structured Scopes and Grant Types to enable this outcome follow:

Preliminary concept slides: Overview Slide Deck (this is the deck presented to the UMA working group) 

Example Scopes for a PDS and how they could be used to enable the new Terms of Authorization contract type:

• Read Authorized Data in a Principal’s PDS Described Resource
• Modify Authorized Data in a Principal’s PDS Described Resource
• Add Authorized Data to a Principal’s PDS Described Resource
• Delete Authorized Data from a Principal’s PDS Described Resource

Note, by way of example, the Yahoo implementation of AUth 2.0 scopes for API calls by approved developer apps that have been granted authorization by a Yahoo Under include:

• Read/Write Yahoo! Updates
• Read Yahoo! Contacts or
• Read (Shared) Yahoo! Profiles 

This last sample Scope type would have a syntax, for example, like this: “GET: Read (Shared) Yahoo! Profiles”

In the case of the OpenPDS and approved Services that use geo-location information the syntax for a scope following the Yahoo approach might be something like this:  “GET: Read PDS Location” and include any limits on duration of the authorization. 

The UMA OAuth 2.0 Resource Set Registration draft provides this example scope:

{

  "name": "View",

  "icon_uri": "http://www.example.com/icons/reading-glasses"

}

The scope is then applied to a named “Resource Set Description” to establish what Personal Data the Principal User is granting authorization to access in some way.  The syntax of the Resource Set Description is:

{

  "name": "Photo Album",

  "icon_uri": "http://www.example.com/icons/flower.png",

  "scopes": [

    "http://photoz.example.com/dev/scopes/view",

    "http://photoz.example.com/dev/scopes/all"

  ],

  "resource_set_type": "http://www.example.com/rsets/photoalbum"

}

Following the UMA approach, the OpenPDS and approved Services that use geo-location information syntax for a scope to access and copy geo-location data might look like this:

{

  "name": "Location Data",

  "icon_uri": "http://www.example.com/icons/map.png",

  "scopes":

    "http://OpenPDS.com/Rules/scopes/read",

],

  "resource_set_type": "http://www.example.com/rsets/location"

}

And if a limitation on access to only location data related for the year 2011 was supported, then the scopes could look like this:

{

  "name": "Location Data",

  "icon_uri": "http://www.example.com/icons/map.png",

  "scopes":

    "http://OpenPDS.com/Rules/scopes/read",

    "http://OpenPDS.com/Rules/scopes/2011"

  ],

  "resource_set_type": "http://www.example.com/rsets/location"

}

Example Integration

Example integration of the “Legal_Term” into the “Terms_of_Authorization” section of the “Terms_of_Agreement” contract between the user and service provider, aka “terms of service” “terms and conditions of use” “terms of use” etc.

The Grant Type is to “Access and Copy” Personal Data (aka “read”).  The syntax of the Grant Type would include a fragment of an English sentence that, when queries and inserted into an expected location on the HTML page comprising the Terms of Authorization will complete an entire legal provision.  By the same method, the Scope Type to “Get: Read PDS Location” would have an English sentence fragment associated with it as well which would likewise be dynamically incorporated into an expected location on the legal agreement page to complete the relevant terms relating to the names of the parties and the agreed rights, obligation and specific boundaries, stipulations or other requirements or constraints related to the authorization provided and the legal duties agreed by the Requesting Party and both directly and also through the Requesting Party  The following examples shows how the user contract dynamically include the orange orange directly from the Scope and other relevant parameters to both enforce technical rules and compete enforceable legal rules. 

[DEMO EXAMPLE SECTION OF USER TERMS OF AGREEMENT]

{

Terms of Authorization:

Furthermore, You and the following Parties agree that:

"AcmeNoteCo" is Authorized by You to "Access and Copy" your "Personal Location Data"  Collected During "2011" and may use this Authorization until "December 31, 2012", subject to non-conflicting terms of "AcmeNoteCo" legal agreement with You at "AcmeNoteCo.com/ToS". 

}

In the above example the terms in quotes and rendered in red are pulled directly from the Resource Server records of scope grants, including scope type and relevent resource set and limits. 

Relationship to UMA Binding Obligations.

The UMA Binding Obligations current specification (  ) proposes use of the following general construct for a method of correlation of legal terms and technical actions and flows: "[Clause ID]. When [protocol interaction takes place], the [obligated Subject] gains an obligation to the [expecting Subject] to [behave in a particular way]."  The overall context contemplated by the Model Rules supports this general approach, however, some of the aspects are manifested through other means.  The focus of the “Terms of Authorization” is to specifically and dynamically converge into the human readable contract between the “user” and their” personal data service” and a “third party” each of the named parties and particular rights and obligations associated with the grant type and scope that have been authorized.  This somewhat narrow focus, it is intended, will serve as a sound foundation and reusable, extensible and scalable mechanism to eventually ensure a verifiable synchronization point for integration of intended business, legal and technical arrangements and expected results.  

Furthermore, the UMA Binding Obligation explicitly excludes from it’s scope both:

• When an Authorizing Party registers for an account at a Host, the Authorizing Party might gain an obligation to the Host Operator to adhere to the Host Operator's terms of service. And
• When a Requester registers with an AM for OAuth client credentials (for example, through an explicit approval process or through a passive "API-wrap" process), the Requester Operator might gain an obligation to the AM Operator (apart from any particular Requesting Party's usage of that Requester) to adhere to the AM Operator's terms of service for API clients.

These are precisely the two pivotal points that are leveraged by this implementations in order to ensure minimally adequate legal terms exist.  UMA Binding Obligations does anticipate several types of circumstances that give rise to legal obligation applicable to parties that would use UMA.  They are:

• When an Authorizing Party registers for an account at a Host, the Authorizing Party might gain an obligation to the Host Operator to adhere to the Host Operator's terms of service.
• When a Requester registers with an AM for OAuth client credentials (for example, through an explicit approval process or through a passive "API-wrap" process), the Requester Operator might gain an obligation to the AM Operator (apart from any particular Requesting Party's usage of that Requester) to adhere to the AM Operator's terms of service for API clients.
• When a Subject becomes a Requesting Party Agent for a Requesting Party (for example, through an employment agreement), the Requesting Party Agent might gain an obligation to adhere to any agent agreements in place in the Subject's UMA-related interactions performed on behalf of the Requesting Party.
• When a Requesting Party contracts with a Requester Operator to engage in UMA-related interactions on the Requesting Party's behalf, the Requester Operator might gain an obligation to adhere to the terms of that contract. For example, a car dealership may contract out to use a cloud service that crawls the Web looking for personal RFPs that meet the dealership's criteria, and want to impose confidentiality requirements.
• When a Requester accesses a protected resource at a Host, the Host Operator might gain an obligation to the Requester Operator to be trustworthy as a source of the expected data. For example, in a scenario where the Requesting Party is also the Authorizing Party and is trying to fill in an online loan application through an online financial service (the Requester), where the Host Operator provides credit risk data about the Authorizing User, the Requester Operator will want to authenticate the Host service in some fashion.

To a greater or lesser extent, each circumstance described above, as well as others, are intended to be leveraged by the approach underlying these System Rules in order to enhance the probability of all parties being able to rely upon predicted legal outcomes.

The hack-a-thon in January at the MIT Media Lab will develop scopes and grant types and harmozize the associated legal terms and work flows reflected in a reference implementation of the MIT Model System Rules applied to the postulated PDS provider system to result in this new type of legal and technical converged code and contact.