(Sorry for the delay! Hmm, the table contents don't seem to be showing here, so please follow the link to see them.) https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note... 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 https://kantarainitiative.org/confluence/download/attachments/77300164/UMA_p... 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 [image: (smile)] ). 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 https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/vDl5Q3czOg...) 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