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.
...
We examined the outputs of the ad hoc meeting of last week (in slides form). The use cases drive the state machine. So you enter it at whatever point depending on the real-world circumstances. There's a question about which system you're interacting with in each use case. E.g., an employee system is an RS that holds hours worked, paid time off, etc., and personal data management is divided up between RS's. We may have to try this with use cases from different industries and see how it comes out. But presumably any single "run" of the UMA protocol only involves a single cohesive system that interoperates.
...
We could leverage a table as well for describing the states.
| DS involved | DS not involved | |
|---|---|---|
| Single administrator | State1: Self-management | State3: Management under care |
| Multiple administrators | State2: Co-management | State4: Co-management under care |
That might be a useful way to discuss those two factors in common for a lot of the scenarios. We're not sure if there is a third dimension. Could any one resource have RRAs that have to "split" along these lines? E.g., Joe and Jane have a joint bank account. Joe is competent to self-manage it, but Jane becomes ill and wants to designate a third party, not Joe but her attorney Jim, to manage the account for her. And then something happens to Jim... It's delegation turtles all the way down. How realistic are some of these? There are legal constraints on continuing to add further and further delegates. But at some level, US laws such as RUFADAA (which is more widely adopted than ever – later Tim provided adoption status in email) could provide a basis for at least the first layer – or maybe as far as two layers? – of delegation to be handled at a "policy layer expressed by technical means" with UMA's help.
...
- 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
...