...
- Fridays, 8-9am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas - NOTE:IGNORE the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line)
- UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar
2016-04-29
- Accountability (data controller) vs. responsibility (data processor) in relation to the data subject (this topic came up at our UMA Legal IIW session)
- Terminology: the next generation – can we tackle Grantee subtleties next?
- What is the right structure for UMA Legal work and review? (this topic came up at our UMA Legal IIW session)
Attending: ...
2016-04-15
- Grantee and Resource definitions; how to handle role stacking (Grantor can be Resource Subject, RSO can be ASO, etc.) – handle in a generic way? (see this thread)
- (Based on input from Scott D.) RSO - ASO model clauses (original proposal):
- How to parameterize to enable different legal models for handling the granting of "access"?
- How to identify/parameterize to enable exceptions to normal access/non-access? (see decision tree)
- How to handle notification requirements?
Attending: Eve, Ann, Adrian, Jim, Kathleen, Mark
Adrian's idea for an IIW session: UMA and GDPR.
Do our model clauses actually want to be broad enough to serve the use cases for things like the enterprise as a resource owner/Grantor? So far, we do have a definition of Grantor etc. that admits a Legal Person (e.g. an enterprise or government agency or whatever).
HL7's definition of grantor: "An individual who agrees to confer certain rights or authority to a grantee." A grantee is: An individual who accepts certain rights or authority from a grantor." The various ISO and EU standards discuss collection, access, use, and disclosure. Unfortunately, they didn't think of the case where API access is about other HTTP verbs than GET 
, where the client might be putting data for which it's authoritative back into the server, or whatever; in these cases, collection, use, and disclosure could sort of be reversed. This is why "access" so often carries the burden for the other three.
Jim believes: "A goal might be to create text handles for each of the foreseeable circumstances. So, a complete vocabulary seems better to me." So shall we define the full set, then? We would theoretically know when to use which phrase (potential vs. real) in each clause. After all, the "potential Grantee" doesn't have consent, right? Why conflate?
What about carefully staying away from applying a specific legal theory to underlie the agreement (e.g. license)? We've already put out of scope the different agreement life cycle templates; Jim has done a ton of work on this in CommonAccord. (Kathleen is interested to learn about this so she can apply them in status definitions in the HL7 contract work!) Essentially, we think staying away from picking normative legal contexts, including workflows, is still out of scope, so wherever this might "intrude" on our clause text, we'll need to figure out how to parameterize the text.
Next time without fail: Let's focus on the #RSctrl clauses needed (which may be part of the RSO - ASO trust relationship and also part of the RSO - Grantor (Potential Grantor?) relationship). See the Jan 15 notes for four use cases, and also realize that we have to take into account a fifth use case of "requested access outside of normal UMA mechanisms".
We discussed the GA4GH work on "ADA-M"; they're developing what look like model clauses for the sharing of genome data.
...