http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... 2016-03-25 - Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review Attending: Eve, Paul, Kathleen, Adrian, Jon N, Ann, Jim We reviewed our model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/> with model definitions <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/Terminology/Terms_0.md>, with recent changes. What's the deal with the "D word" – delegation? If we qualify "delegation of *what*", then we can observe that there are several types, and we can map them to different trust relationships we have identified: - Resource Subject - Grantor (not in scope): This enables a "resource owner" to find someone else to actively manage resource access for them at an AS. - Grantor - ASO: This enables an always-on AS to be available to execute the wishes (policy conditions) of the Grantor. - RqP - Client Operator (not in scope; also not previously discussed as a model definition...) - Grantor - RqP Discussion about Grantor - RqP: Adrian doesn't think this is an appropriate use of the word "delegation". Eve believes "that train has sailed". [image: (smile)] See, e.g., the NZ POC <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services> . Regarding Adrian likes the distinction of "If you have a privacy policy, then there's an Operator involved; if you don't have a privacy policy, then you own it/wrote it." (It's personal to you and there's a 1:1 relationship between you and the software/service.) We have a new party with responsibilities now in scope! It's the Client Operator. Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases. Which trust relationship should we dig into first? For reasons of our #RSctrl/#ROctrl use case <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> tension, and because it's the most "upstream" (no dependencies) trust relationship, let's start from RSO - ASO (see the clauses that start ASO... here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/> and the clause that starts with RSO here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/Clause/ASO/> – however, these are old and almost certainly don't reflect our latest discussion). There's a use case that could help us interestingly when we get to working on Resource Subject- and Grantor-involved model clauses, but will need to take into account some out-of-band machinations because it engages precisely the Resource Subject - Grantor relationship: a "digital death" use case. Alice (as her own Grantor) shares some digital data resources with Bob. She wants to arrange for her lawyer to become her Grantor when she dies, so that Bob can continue to get access to those resources. In practice, because of what are known (really) as "time-to-live" strategies around credentials, tokens, and permissions inside tokens, the access that Bob enjoys to those resources is certain to get cut off at some point after Alice dies. Using a combination of business, legal, and (non-UMA – including digital contract) technical approaches, Alice's lawyer can replace Alice as the owner of those resources and ensure through the AS that Bob's access can continue or be restarted. *AI:* Jim and Eve: Extract the two-party reworkings of the old model clauses for at least RSO - ASO and prepare for group review next week. *AI:* Everyone: Think about and approach candidate external reviewers by next week. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl