I suggest we adopt as much terminology from GDPR and PSD2 as we possibly
can and reference the source as we do it.
Adrian
On Fri, Jun 16, 2017 at 12:25 PM, Eve Maler
Thanks to all for a lively call!
http://kantarainitiative.org/confluence/display/uma/UMA+ legal+subgroup+notes#UMAlegalsubgroupnotes-2017-06-16 2017-06-16
- Reviewing pieces of deliverable #3 - All the roles in the use cases - Names and definitions for them - Different ways to connect the legal and technical artifacts and why - The different "solar systems" in the jurisdictional universe
Attending: Eve, Andrew, Kathleen, Thomas, John W, Sal, Tim
*Assumption:* The resource protected by UMA is personal information. Is it always? We'd had conversations in the past about other use cases, such as that the resource is not PI but rather "confidential information", or "IP", or something else that's not "PI". This subgroup's mission makes clear that it's about "protecting privacy rights", so it suggests that other use cases, such as protecting these other kinds of information (which is useful for both natural and legal persons as resource owners), are out of scope. We should state this somewhere in the final deliverable – not that the framework couldn't reasonably (or even easily?) be extended for these purposes, but we haven't chosen to focus on them at this time.
*Data Subject* shortens to DS (vs *Resource Subject* and RS), and then it wouldn't clash with *Resource Server*/RS. *Data Subject* is the canonical name in GDPR, the ISO privacy framework, and pretty much all "privacy talk" around the "trinity" of data subjects, data controllers, and data processors. Let's make it so!
If you have a *Client Operator* (say, Google running a *Client*, Google Calendar) and a *Requesting Party Agent* (this is our current term under discussion) – say, Dr. Bob using the Google Calendar *Client* – who is using it under the control of the real *Requesting Party*, a hospital institution – is it abundantly clear that the CO is distinct from the RqPA? Here is how the RSO and the CO each have a legal relationship with the ASO distinct from other/higher-order relationships:
- The RS gets OAuth client credentials from the AS, and there is an opportunity (currently nearly always taken) for the ASO to impose an agreement on the RSO before issuing these credentials. - Similarly, the C gets OAuth client credentials from the AS, and there is an opportunity (currently nearly always taken) for the ASO to impose an agreement on the CO before issuing these credentials.
When we wrote the old Binding Obligations clauses, we put clauses having to do with the client credentials stage out of scope. However, UMA2 requires https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#author... the client to take certain actions at registration time (meaning, before the requesting party – NOTE: or, requesting party agent) is wielding that client software. This means effectively that the client's interactions at that registration juncture are on the "legal stage" for us, licensing-wise – so we seem to need a new table for client credentials for each, even if we may not need model clauses for one or both. The requesting party agent note is about the fact that Alice the patient might give access to "a doctor's practice" overall to get access to her calendar for scheduling her pre-op appointment. The receptionist ultimately gains access under this policy. The receptionist isn't "the practice", but an agent of the practice doing work for hire. The calendar is being used by the receptionist (*Requesting Party Agent*) but is "operated" by Google the company (the *Client Operator*). The idea is that the CO would be bound by any license formed through the client credentials issuance timeframe, the RqPA would be bound by his/her employment agreement with the "true" RqP, and the "true" RqP would be bound by the end-to-end RPT licensing through the main UMA Legal framework.
The Word doc uses "Consent License". Why not "Use License" or just "License"? In order to market the framework as being able to solve a large class of consent challenges, it seems we need not put an adjective on "License" – just talk about our solutions in other ways and parts of our framework documentation. Is it worth talking about "Data Protection Licenses"? Or maybe this is a "licensing framework", and we ultimately produce a "licensing toolkit", and hey, maybe a "licensing API" that can be called! The agreements others produce with it could be whatever kinds of agreements they need to produce! Given that the agreements others produce might be dynamic (while versionable etc.) and dynamically negotiable – while we reduce the friction to making them protective of privacy rights – we don't necessarily want to apply old-fashioned labels too soon.
*Resource Owner* vs *Grantor* as a name is still an open question. HL7 uses Grantor in a way that seems to only apply when the person is the offeror (?) of license terms. But in UMA, this person could be either the offeror or accepter of license terms, based the UX. Or is that true? This is an open question. Eve is starting to suspect that, regardless of flow, the RO/G is always the offeror.
If Eve's assumption is correct, the next open question Eve and Tim had discussed is: Despite the "chain of agents/legal representatives" that may exist, does the offer of license terms always rest at the Data Subject somehow? E.g.:
- *Data Subject* little Johnny (2yo) - ...has an Agent/Legal Representative (she's probably the latter because Johnny's a minor) mom Alice, who sets some policies on Johnny's behalf but also - ...chose an Agent, Authorization Server Operator ShareHub, which sets up some default policies and security protections - Alice shared Johnny's EHR in selective fashion - ...with RqP research organization NYP through CO *autonomous web client* Sync4Science Scraper - ...which gives downstream access to employee researcher RqPA Charlie
Alternatively:
- Data Subject little Johnny (2yo) - ...has an Agent/Legal Representative mom Alice, who sets some policies on Johnny's behalf but also - ...chose an Agent, Authorization Server Operator ShareHub, which sets up some default policies and security protections - Alice shared Johnny's EHR in selective fashion - ...with researcher RqPA Charlie using *web or mobile C app* Research Viewer - who gives access to the broader research organization because of his employment relationship
Is the transfer of "access grants" or of a "right"? And do we stick with "Grantor", do we move back to "Resource Owner", or change entirely to something like "Data Subject Proxy" or "Data Subject Agent"? This person may have relationships with a lot of ASOs, and in some cases it's on their own behalf, and in others it's on behalf of others. There is no UMA artifact that documents on the wire (maybe on the wire in the medical world, in some circumstances?) the relationship between these two roles. See our matrix from the 2016-03–18 telecon http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... for all the relationships and technical artifacts. The way the NZ government solved this was to invent a "headless" account for the offline person, and then have the institution manage the account on the person's behalf.
Eve's suggestion for a followup from Tim: Enumerate and recommend answers for all the outstanding questions above.
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list 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.