Hello,
Thought I should share my thinking in writing before the meeting:
Regarding multiple DS’es the table would look like this.
The Multiple DS case may not occur often, but is present in the case of a shared bank account between partners.
When a couple opens a bank account, they may start at State 5, when one of the couple goes under care, they transition to State 6,
When one of them dies, the end state is State 1 if the other partner is the sole beneficiary, or if there is another person, it may go back to State 5, or State 7 etc.
Not sure how to represent this technically – it seems to work for DS=2; not sure it extends to a larger number.
Do we have cases where DS is greater than 2.
DS>1 | Rep>0 | Carer>0 | State
F | F | F | State 1: Self-management (Single DS)
F | F | T | State 2: Management under care (Single DS)
F | T | F | State 3: Co-management (Single DS)
F | T | T | State 4: Co-management under care (Single DS)
T | F | F | State 5: Self-management (Multiple DSes)
T | F | T | State 6: Some/All DSes under care (Multiple DSes)
T | T | F |State 7: Some/All DSes co-manage with Reps (Multiple DSes)
T | T | T |State 8: Some or all DSes under care and co-managed (Multiple DSes)
Thanks,
--Cigdem
From: WG-UMA <wg-uma-bounces@kantarainitiative.org> on behalf of Eve Maler <eve@xmlgrrl.com>
Date: Wednesday, 31 July 2019 at 19:05
To: "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org>
Subject: [WG-UMA] Notes from 2019-07-30 UMA business-legal telecon
(Sorry for the delay! Hmm, the table contents don't seem to be showing here, so please follow the link to see them.)
2019-07-30
Attending: Eve, Andi, Cigdem, Nancy, Vladimir Prihodko (works at Lush Group, has implemented UMA1 there), Domenico, Colin, Tim; regrets from Lisa
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.
If you're operating at the technical layer, by definition it sort of all "works out" because the protocol defines how things work, but at the policy layer, questions creep in: having
multiple ROs (RRAs) is like science fiction (the multiple-worlds hypothesis 
).
If multiple RRAs can set policy, does one's policy override another's, or do they combine, or do they get "shares" in the policy in aggregate, or what? These could all be different use cases. We know of some common ones, like where the parents (or set of guardians)
for a child have to all agree to release the medical records of a child. But we don't have to figure out how to implement this, just acknowledge that ASOs need to be free to meet the needs of their users.
We could leverage a table as well for describing the states.
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.
Is "policy layer" the right name? The overall generic name has been "business-legal" but that may be too awkward. Let's continue this topic.
Would it be possible to define the policies themselves to make them interoperable? To be discussed.
Questions we still need to discuss as outlined in the slides:
For the care scenarios, do we need a primary carer/super admin type of role or are all entities in RRA equal?
Federated authorization or not? Arguably, personas of a DS and a single DS have the same identity verification risk. If personas, then ”DS” in the state machine is replaced with “persona”.
The key assumption: KYC works – if that fails, all the rest fails.
Eve Maler
Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl