Standing agenda for 2019: Work on producing our second business model 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.
...
"Legal" topics are currently being covered in a separate business model meeting series. See the UMA calendar, and the main Meetings and Minutes page, for details.
2019-05-21
Attending: Eve, Nancy, Lisa, Tim, Cigdem, Adrian, Domenico, Mark
Our goals in filling out the new use cases spreadsheet are:
- Make crystal-clear the legal-technical mappings
- Link to definitive definitions (and figure out which concepts need new terms and better definitions, and figure out if we need to refine our definitions in a new report vs. the first report)
- E.g., define a new Proxy/Agent/whatever term? Define a term for an organization that is the equivalent of a "data subject" (the information is "about it") only it's not an individual?
- Get people to put their hands up in identifying which use cases they care about, and add new use cases
- Figure out how to incorporate all the necessary complex information into licenses, such as covering Requesting Agents and Requesting Parties as required (Dr. Bob and the institution he works with, e.g.)
Our hope is that there are some kinds of licensing that you can boilerplate, a la Creative Commons. That has been the premise behind our looking at CommonAccord.org, which literally has a GitHub system for reuse of legal text (and the Ricardian system in general: prose, code, parameters). Also, jurisdictions will suggest some similarities. (See our very early UX work.) But there is extreme variability that can arise based on things like the types of resources and scopes; for example, "getting some data" is different from "controlling a smart camera".
Adrian suggests following up to learn about the work of this group.
2019-05-07
Attending: Eve, Adrian, Cigdem, Domenico, Colin, Lisa
...
- 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
...