Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
- Business-Legal Framework and Use Cases (GDoc)
- Mapping Graphics (GSlides)
- Legal Role Definitions (GSlides)
- Definitions and Use Cases Spreadsheet (GSheet)
2019-11-05
Attending: Eve, Nancy, Tim (regrets: Cigdem, Andi)
We have been dealing with the "multiple RRAs" state table as if there is always and only a single DS. For simplicity, perhaps we should continue in this vein. It would be insanely complex to imagine that there are multiple DS's as well. The "co-equal rights" question is about resource administration rights specifically. However, a number of real-life use cases have the "multiple DS" situation: joint bank accounts where both account holders should have exactly equal rights, etc. In implementation, this is a problem and is generally handled badly, in that one person is made "primary" and the other(s) "secondary. In some use cases this divide is appropriate (main householder vs. other people in the household for digital streaming services), but for things like a joint bank account or other spouse-type membership accounts, both/all holders should really be co-equal – until such time as there is a divorce or other split and the number of DS's goes back down to exactly 1. What if two brothers share a bank account and one of them has to be removed from managing it for malfeasance and the other brother is managing it for the two of them, somewhat like in the Gravity Payments case?
To clarify whether we need to focus on multiple-DS use cases and whether they are sufficiently valuable to solve, Eve will ask an FSI/bank expert to join us at our next meeting. Nancy will do the same for a genomic data expert.
The current use cases that we've mentioned under State 3 in the table ("joint bank account each with equal access, joint tenancy") look like they're not actually correct because they probably refer to multiple DS's, so we have to sort out whether we're going to treat multiple DS's or not, and move the use cases over if so.
AI: Nancy and Eve: Find experts to join our next call to establish existence and priority of multiple-DS use cases in different sectors.
2019-10-29
Attending: Eve, Cigdem, Nancy, Andi, Adrian, Tim (regrets: Domenico)
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...