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.
...
(Notes from the 2015 series were kept in email: 2015-08-06, 2015-08-14, 2015-08-21, 2015-08-28, 2015-09-04, 2015-09-11, 2015-09-25, 2015-10-02, 2015-10-09, 2015-10-16, 2015-10-23, 2015-10-30, 2015-11-06, 2015-11-20, 2015-12-04, 2015-12-11, 2015-12-18.)
Date
...
, Time, Documents
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details. Current documents being worked on (WG participants will receive edit access for the asking; others may receive view access):
- Business-Legal Framework and Use Cases (GDoc)
- Mapping Graphics (GSlides)
- Legal Role Definitions (GSlides)
- Definitions and Use Cases Spreadsheet (GSheet)
2019-10-22
Attending: Eve, Colin, Nancy, Andi, Domenico
We worked directly in the document, accepting suggestions and editing the results.
We discussed whether we should keep "Alice" for consistency as the resource owner name, vs. use variety (e.g. the "Jane" example as in Andi's new "simple example up top).
AI: Domenico: In the Mapping Graphics slide 19 graphic, can he please ensure that the "technical terms" (currently with no-color background outside the legal terms) be distinguished somehow (maybe with italic or with a color background) and be all lowercase?
In the Typical Use Case section, let's try telling a brief narrative story about the life insurance use case, either before or after the technical definitions, so as to make it easy for nontechnical readers to understand those definitions. We do need the technical definitions – otherwise we can't delve into the permission token/license work that the paper needs to do.
2019-10-01
Attending: Eve, Andi, Domenico, Nancy, Tim, Cigdem
...
- 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
...